How to Build and Run an FFXIV Free Company Discord Server With YourBot

Build an FFXIV Free Company Discord around three separate needs: a welcoming community, organized activities, and controlled access to FC or static business. Use YourBot’s Start Your Server to prepare the channels, roles, permissions, and supported service settings, then finish the member-facing workflows in their dedicated dashboards.

A good server helps a new player find company without revealing the story, gives a raid leader a usable roster, and lets a crafter help someone without searching through yesterday’s chat. Those are different jobs. They should not all depend on one busy #general channel.

This guide follows Lanternlight, a fictional Free Company on Faerie, Aether, with social members, returning players, crafting projects, and an eight-player static that also accepts friends from outside the FC. Its example raid schedule is Wednesday and Sunday, 8–10 p.m. America/New_York.

The names, schedules, limits, and policies below are recommendations—not YourBot defaults or a real customer deployment. The manual setup sections also work for an established server that keeps its existing layout.

Start With the FFXIV Distinctions That Matter

A Free Company is an in-game organization associated with a Home World. A static is a regular team assembled for an activity, often high-end duties; its members do not have to belong to the same FC. A cross-world linkshell is another communication arrangement, not a replacement for either membership structure. Square Enix’s Community Finder distinguishes FC and cross-world recruitment.

Build access accordingly. An FC member should not automatically receive a place on a progression roster. An outside static member should not automatically see company finances, recruitment discussions, or workshop decisions.

Likewise, Discord membership is not in-game membership. YourBot verification, application acceptance, and event signup do not themselves join an FC, validate a Square Enix account, unlock a duty, or change a character’s in-game rank.

Write a short community brief before configuring anything: Home World, logical data center, language, usual active hours, social expectations, spoiler policy, recruitment contact, and activities the FC actually runs. Keep progression commitments in the static’s own agreement.

Give social participation a complete path of its own. A person who enjoys maps, gathering, decorating, or helping sprouts should not need to become a raider to feel like a full member.

Give the Ten YourBot Services Distinct Jobs

These are built-in services, not ten separate bot invitations. Review the current subscription and AI pricing; optional marketplace plugins can have developer-set charges. Give every enabled service a staff owner, and leave optional features disabled until someone will maintain them.

1. Separate Membership, Staff Authority, and Interests

Use a small role system with explicit responsibilities:

Allow multiple gameplay roles because someone may play several jobs. The job they select for a particular event is a separate commitment. The official job guide is a useful reference for role categories.

Keep the bot above roles it needs to assign. Administrator does not remove Discord’s role-hierarchy limits. Also, two roles with access do not automatically create a “must have both” rule. Check Discord’s permission behavior, then test combinations such as an outside static member who is not in the FC.

Your FC’s in-game member ranks and chest permissions remain separate. A Discord officer role must not be treated as evidence that someone can withdraw gil, manage company actions, or administer an estate.

2. Build the Foundation With Start Your Server

First create or choose your Discord server and connect its bot through YourBot’s Bot Settings. Follow the guided application and token setup there; never put the bot token in a planning prompt, application, or support conversation.

Sign in as the Discord server owner, select the server, and open Start Your Server. Check which bot appears under building as. That application needs the relevant visibility, Manage Channels, and Manage Roles permissions for the approved work.

Start with a description like this:

Build a compact Discord server for Lanternlight, a fictional FFXIV Free
Company on Faerie, Aether, North America. We welcome story players,
returning players, crafters, gatherers, and social members. Static A raids
Wednesday and Sunday, 20:00–22:00 America/New_York, and includes friends
who are not FC members.

Separate Community Member, FC Member, Static A, Officer, Recruiter,
Moderator, and Welcome Guide roles. Welcome verification grants only
Community Member. FC Member and Static A require staff decisions.
Gameplay interests and notification roles must never grant staff access.

Create a small welcome/rules area, role selection and applications,
community chat, newcomer help, event signups, duty LFG, and crafting chat.
Create FC-only company information and projects. Give Static A a private
planning channel and permanent voice room without exposing FC-only areas.

Keep ordinary channels spoiler-safe. Put story discussion and Lodestone
news behind separate opt-in roles. Do not expose those channels through
new-member defaults. Use neutral channel names and no story images.

Create one Join-to-Create voice lobby for spontaneous parties. Start with
four-person rooms, delete them when empty, and keep it separate from the
permanent static room. Create private recruitment review, moderation log,
ticket log, and analytics alert destinations.

Enable Welcome, Tickets, Sentinel, Beacon Events, Group Finder, temporary
voice, Announcements, Social Feeds, and Analytics with supported settings.
Prepare an optional giveaway destination, but leave Giveaways disabled
until we are ready. We will manually review applications, event templates,
announcement schedules, feed subscriptions, and any giveaway.

Use Welcome-based onboarding initially. Do not enable Discord Community
Onboarding or broaden @everyone access merely to meet its requirements.
Preserve existing roles, channels, and active safety configuration. Propose
no deletions. Put new moderation rules in log-only mode; do not enable
additional punitive actions. Show the remaining manual work.

Review the layout, not just the conversation

A manageable starting design is:

START HERE — newcomers
  #welcome-and-verify
  #rules-and-fc-info

COMMUNITY — Community Member
  #choose-roles
  #apply-and-contact
  #general
  #new-player-help
  #event-signups
  #duty-lfg
  #crafting-and-gathering
  #announcements

FREE COMPANY — FC Member
  #company-notices
  #company-projects

STATIC A — Static A and its authorized staff
  #static-a-planning
  Static A Voice

OPT-IN AREAS — channel-specific access
  #story-spoilers
  #lodestone-news
  #member-streams      (optional)
  #giveaways           (optional)

VOICE — Community Member
  FC Lounge
  Create Party Room

STAFF — access limited by responsibility
  #officer-chat
  #recruitment-review
  #mod-log
  #ticket-log
  #analytics-alerts

“Opt-in areas” is an organizational label, not a shared access grant. Configure each channel separately so opting into streams does not expose story spoilers. Keep information, announcements, and bot listing destinations read-only where appropriate.

In the builder, inspect Channels, Roles, and Services, use See it as, and review the Safety check and individual operations. Test the perspective of a newcomer, ordinary community member, FC member, outside static member, and recruiter. Keep deletions unchecked.

Save the pre-build snapshot and inspect the result. Structural recovery cannot recreate messages from a deleted channel. The Start Your Server documentation explains the approval and recovery process.

Enabling is not finishing. Supported service settings can be prepared during the build; actual Announcements schedules and Social Feeds subscriptions still require manual setup. Review detailed forms, role menus, and event templates in their own services afterward.

3. Configure Welcome Without Excluding New Players

Open Welcome → Settings, choose #welcome-and-verify, and write a greeting with the next action clearly stated:

Welcome to {server}, {user.mention}!

Read #rules-and-fc-info, then use Verify to enter the community.
Choose optional roles in #choose-roles and ask questions in #new-player-help.
FC recruitment and private officer contact are in #apply-and-contact.

You can enjoy the Discord without joining the in-game FC.
General channels are spoiler-safe. Story and news channels are opt-in.

Replace channel labels with real Discord channel mentions when configuring the message.

Enable verification, select the verification channel, and choose Community Member as the Verified Role. Save the settings, then use Post / Update message. Do not select FC Member or Static A as the automatic grant.

Build role menus for gameplay interests, activity pings, and spoiler choices. Keep staff and membership roles out of those menus. Make an introduction welcome rather than compulsory; someone should be able to ask for help without composing a character biography.

Make a real path for Free Trial players

Square Enix’s Free Trial restrictions prohibit creating or joining an FC and restrict trading, markets, party creation, PvP, and Ultimate participation. Trial players can still join parties through invitations or Duty Finder.

That makes community membership without FC membership important. Offer help with eligible duties and have another player organize the party. Do not make an item donation, player trade, or in-game FC invitation a prerequisite for Discord access. Avoid naming your probationary Discord rank “Free Trial,” which confuses an account restriction with your recruitment process.

Use the existing Buddy System

Assign Welcome Guide to willing volunteers, enable Welcome’s Buddy System, and select that Buddy Pool Role. Customize the introduction and decide whether buddy DMs are appropriate. Provide a public help route because a DM may fail.

Welcome Quests can support a few simple Discord onboarding tasks. Keep their purpose social; they do not prove main scenario quest (MSQ) completion or duty unlocks.

For this compact, role-gated FC, Welcome is the initial onboarding path. Discord’s separate Community Onboarding currently requires at least seven default channels, including five where @everyone can view and send messages. Use it when that model fits—not by opening private or spoiler channels to satisfy the requirement.

Test: a newcomer can verify and ask for help, but cannot enter FC, static, officer, or spoiler-only areas without the appropriate separate role.

4. Use Tickets for Applications and Private Staff Contact

YourBot Tickets should provide separate routes for Join the Free Company, Apply to Static A, and Speak to Staff. These requests have different questions and different decision-makers.

For FC recruitment, ask for character name and Home World, preferred activities, usual availability, and what the applicant wants from a community. A Lodestone profile link can help staff find the character, but a pasted URL alone is not proof of account ownership.

For static recruitment, add intended job, alternatives, relevant experience, availability with time zone, and the agreed progression goal. Do not ask casual FC applicants to submit a progression résumé.

Create the intake forms, configure the appropriate staff teams, then create the panels. Applications can use Form (review queue — no channel). Set a private review destination and the acceptance/rejection messages. Leave Role granted on Accept empty when an in-game membership check still needs to happen; assign FC Member after the officer completes that check and invitation.

Static acceptance can grant Static A when configured, but must not also grant FC Member. Keep sensitive static evaluations separate from general recruiter access when the same people do not handle both.

Use private ticket channels for conversations that need back-and-forth discussion. Point logs and transcripts to a restricted destination, document retention, and set response expectations volunteers can meet. An SLA is a staff target, not a promise of round-the-clock coverage.

An in-server ticket is not an appeal route for someone already banned from that server. Provide an independently accessible contact method for those cases.

Test: submit each application, review it as the intended staff member, and verify that an unrelated member cannot see the submission, decision, or transcript. Confirm that accepting an FC application does not mistakenly imply an in-game invitation occurred.

5. Make Spoiler Safety a Working Permission Model

Write a rule that people can follow:

General channels are story-safe. Ask what someone has completed before discussing plot details. Put revealing names, screenshots, videos, and speculation in the appropriate opt-in area. Mark spoilers inside mixed-progress discussions, and do not reveal the answer in the title or preview.

Discord’s spoiler formatting supports ||hidden text|| and marked attachments. It does not turn a public channel into a private one, and text inside a code block does not gain spoiler protection from the same markup.

For a small FC, start with one clearly labeled all-story-spoilers channel. Add expansion-specific spaces only when there is sustained demand. Explain precisely what opting in exposes; a generic “Level 100” role is not a reliable story-completion gate.

Treat news as potentially revealing too. Lodestone headlines, video thumbnails, livestreams, event images, and duty names can spoil content before anyone opens a message. Keep news opt-in, use neutral public event titles, and suppress unnecessary previews in shared help channels.

Make two checks: what an ordinary member can read, and what the bot can post into public announcements, calendars, or listing pages. Do not assume an app’s web view automatically inherits every Discord channel restriction.

6. Configure Sentinel for Community Safety

Open Sentinel, choose the moderation log, identify the moderator roles, and configure the quarantine role. Start with a protection preset appropriate to your community and inspect the rules it creates.

Run new rules in log-only/dry-run mode first. Test legitimate strategy links, repeated recruitment questions, crafting lists, and enthusiastic event messages before enabling enforcement. Review automatic raid and risk-based actions separately; making individual rules log-only is not a guarantee that every other automatic action is disabled.

Give staff a short policy for harassment, unsolicited recruitment, scams, spoilers, and unwanted pings. Warn members never to submit Square Enix passwords, one-time codes, or Discord tokens through an application or “verification” conversation.

Use human review for context-sensitive disputes. Do not turn a disagreement about play style into automatic punishment, or treat a keyword filter as reliable story-spoiler detection.

Test: trigger a harmless test rule, inspect the record, reverse any test action, and verify the quarantine role cannot accidentally retain access through another role. Retain a manual Discord moderation procedure for bot outages.

7. Build FFXIV Event Templates in Beacon

Use Beacon Events for scheduled activities. Before configuring a template, decide its objective: first-time story help, learning, progression, a clear attempt, repeat clears, collecting, or a social gathering.

A signup should explain what people are agreeing to—not merely that eight positions exist.

In Beacon’s settings, choose #event-signups as the announcement destination. Review reminder defaults and, when using automatic event voice, its parent category and signup-only access setting. Keep shared event posts neutral; private static discussions belong in the team’s restricted area.

Use the right party structure

DPS means damage-dealing jobs. These reflect common duty structures documented in the Eorzea Database for four-player dungeons, eight-player raids, and standard alliance raids. They are not universal requirements for every duty, unrestricted run, or special mode.

Configure an eight-player session

Open Beacon’s event/template editor and choose Start from Scratch rather than accepting a generic Raid Night or Dungeon Run starter unchanged.

In Event Info, enter a neutral title, the actual date, a description, and Max Participants: 8. The Date & Time field uses your browser’s local time. An organizer in another time zone must enter the corresponding local time, not blindly type Lanternlight’s Eastern-time hour.

In Roles, choose FFXIV Party. Its starting structure is two tanks, two healers, and four DPS, with Main Tank and Off Tank tank sub-options. Selecting the role preset does not separately set the event’s participant limit. Check both controls.

For a fixed progression team, you may refine healer and damage roles to suit the roster: one pure healer, one barrier healer, and agreed damage-role positions, for example. That is a team composition choice, not a universal rule for every premade party. Main Tank and Off Tank labels also do not prevent encounter-specific tank swaps.

In Design, add useful requirements, voice, and notes fields. In Actions, choose the signup, leave, tentative, or other buttons you actually need.

In Finish, configure Opt-in, reminders, signup deadline, recurrence, and optional discussion-thread or voice creation. Lanternlight’s example uses reminders 60 and 15 minutes before the session, a 60-minute signup deadline, and Wednesday/Sunday recurrence after a successful test. These are adjustable staff choices.

Keep Static A’s permanent voice room for its regular sessions. Do not also enable automatic event voice creation for the same purpose unless the team deliberately wants temporary rooms.

Write requirements that prevent misunderstandings

Use this event-description pattern:

Objective: Learning / progression / clear attempt / repeat clear
Duty and progress point: Clearly specified in the appropriate spoiler-safe area
Party: Eight players, including the organizer
Meeting: Aether; organizer supplies the current World and party details
Time: Start and finish, with a clear real-world time-zone reference
Entry: Required unlocks and the duty's current level/item-level requirements
Rules: Synced or unrestricted; minimum item level and Echo choices if relevant
Preparation: Agreed strategy, consumables, and any job commitments
Voice: Listening expectations and a text alternative
Rewards: Current eligibility and the group's agreed distribution policy
Changes: How to report absence, lateness, or a job change

Expand unfamiliar abbreviations the first time. “TEA” means The Epic of Alexander (Ultimate); “prog” means learning toward a clear. Do not assume a newcomer knows the current community shorthand for a mechanic or strategy.

Check current duty and patch rules when writing reward eligibility. Do not reuse old “two-chest” language or copy a previous tier’s lockout assumptions into a new event.

A capacity limit is not a permission check or proof of readiness. Static leadership still confirms the roster, substitutes, and job assignments. Do not let an open signup silently displace an established team member.

Test: fill all eight places, exercise leave/tentative/waitlist behavior, check tank sub-options, and confirm a reminder appears at the intended real-world time. Test recurrence across daylight-saving changes before relying on it for a season.

8. Use Group Finder for Parties Forming Soon

Group Finder handles looking-for-group (LFG) requests—“who wants to run something soon?”—while Beacon handles the calendar. Create #duty-lfg as the listing destination and select a private moderation log.

Start with two active listings per member, a two-hour default expiry, and a short posting cooldown. Choose experience labels your community understands, such as First Time, Learning, Progression, Clear, Reclear, Farm, Casual. Adjust these recommendations after seeing actual usage.

Create a dungeon template manually with Party Size: 4 and Tank: 1, Healer: 1, DPS: 2. Do not copy the generic five-person dungeon preset into an FFXIV template. During testing, check how the organizer occupies a slot so four means the entire party, not four additional people.

A useful listing might say:

Aether | Dungeon help | First-time friendly | Starting in 20 minutes
One tank, one healer, two DPS total, including organizer.
We will wait for cutscenes. Ask for a spoiler-safe explanation as needed.
The organizer will arrange the in-game party and confirm the duty unlock.

Use the game and activity fields accurately. Put the logical data center and any rendezvous World in the title or description; a Region value of NA does not distinguish Aether from Primal. Choose the platform option that matches the intended cross-platform group rather than accidentally restricting a general FFXIV listing to PC.

Distinguish two controls: Require Listing Approval means staff approve a posted listing; Join Mode: Request means its leader approves applicants. They solve different problems.

After the Discord group is confirmed, the organizer still arranges invitations or Party Finder in FFXIV. YourBot does not place the characters into an in-game party.

Begin with Local distribution. Treat it as a discovery setting, not a blanket confidentiality promise. Do not put private invitations, personal availability records, or sensitive static decisions in a listing, and inspect any public listing surface before enabling wider discovery.

Test: create, join, leave, approve an applicant, close a group, and let an abandoned listing expire. Confirm ordinary members can complete the workflow and that the displayed party size remains correct.

9. Plan Around Worlds, Travel, and Non-Raid Activities

Record Home World, Home Data Center, and where the activity will happen separately. Being in the same Discord does not make characters immediately available to the same in-game party.

Square Enix’s World Visit guide covers travel within a logical data center. Data Center Travel has its own destination rules and restrictions. Schedule travel before the event rather than at pull time, and confirm everyone has reached the intended data center.

FC chat remains available during ordinary World Visit but is unavailable during Data Center Travel. Company-action effects are not applied while visiting another World under either system. Discord therefore provides useful continuity, but an event plan should not assume travelers retain every Home World benefit.

Keep the content calendar broader than raids:

Maps and collecting: specify the map or objective, meeting World, expected duration, access requirements, and whether members need to bring anything. Agree on ownership and loot expectations before starting. Identify synced versus unrestricted mount runs instead of treating “farm” as a complete explanation.

Hunts: identify the data center, World, area, and organizer’s instructions. Keep hunt notifications opt-in. A Discord signup is not a reserved place or a guarantee that a hunt target will remain available.

Exploration and relics: use separate templates for Eureka, Bozja, and Occult Crescent. Ask for the relevant unlock and progression stage rather than only combat-job level. Likewise, identify the actual relic step before promising a shared farming route.

Deep Dungeons: specify the dungeon, starting point, and whether the run uses a fixed save. In Eureka Orthos, fixed-party continuation has party and job restrictions; generic substitution advice may not work. Eureka Orthos and the Forbidden Land, Eureka are different activities.

PvP and social nights: name the exact PvP mode and check its current queue rules; an eight-slot signup does not guarantee eight players can queue together. For housing tours or screenshots, give the World and location, set a spoiler boundary, and provide a text itinerary.

Rotate accessible events with progression sessions so a returning player can participate before catching up with the latest endgame.

10. Configure Temporary Voice Without Duplicating Static Rooms

Open Join-to-Create Voice Channels and select Create Party Room as the lobby and VOICE as the destination category.

Use a name such as Party — {display_name}, a four-person initial limit, and Delete when empty. Four is a default for this FC’s spontaneous dungeon groups, not a universal FFXIV party size; use the available controls to expand a room when appropriate.

Choose category inheritance or an explicit role allowlist, then test visibility and Connect access. The bot needs the relevant Manage Channels and Move Members permissions to create rooms and move their creators.

Decide explicitly whether Creator owns their channel is enabled. It grants meaningful room-level controls, so explain acceptable naming, access changes, and participant removal. It must not confer control over the permanent static room or the rest of the server.

Provide a written alternative for players who cannot speak, prefer listening, or need instructions in text. Use descriptive names rather than emoji-only labels, and put important decisions in writing after voice discussions.

Test: a member joins the lobby, moves into the correctly named room, admits an allowed friend, and leaves. The room should remain while occupied and disappear after the last person leaves.

11. Schedule Useful Announcements

In Announcements, choose #announcements, write the message, set the Timezone explicitly, and choose its recurrence. Lanternlight might publish a weekly Sunday afternoon reminder to review upcoming activities.

Keep the internal label descriptive—it is for the dashboard, not the Discord post. Include a link to the event area and one clear next action. Leave @everyone and @here disabled unless a particular message genuinely needs them; use opt-in activity roles selectively.

A recurring announcement republishes configured content. It is not automatically a fresh summary of that week’s roster, game news, or FC projects. Update changing information or use an evergreen message that points to the current source.

Keep real-world time, UTC-based reset references, and Eorzean time distinct. A timed gathering node is not scheduled by the same clock as an 8 p.m. Discord raid. Verify game reset rules before publishing a reset reminder instead of hard-coding an unreviewed local-time conversion.

Test: schedule a private one-time message first, check formatting and mention behavior, then enable recurrence. Do not duplicate Beacon’s event reminders.

12. Add the Actual FFXIV Lodestone Feed

YourBot’s Social Feeds catalog includes FFXIV Lodestone, separately from the FFXIV Online Steam-news entry. Use the Lodestone entry for Square Enix’s Lodestone feed rather than inventing a game-news integration.

Open Social Feeds → Add a Feed → Game Patch Catalog, select FFXIV Lodestone, and choose #lodestone-news as the destination. Start with no ping role and the source’s recommended polling interval; the reviewed adapter defaults to 1,800 seconds.

The dedicated adapter uses the North American Lodestone feed, not an automatically region-matched feed based on your FC’s World. Review regional relevance before presenting its maintenance times or notices as local instructions.

Initially leave the include-keyword filter empty. A narrow “patch notes” filter can miss maintenance and service notices. Inspect the output before adding filters, and remember that excluded keywords take precedence. Source publishing and polling timing also mean this is not a guaranteed instant outage alert.

Avoid enabling both Steam and Lodestone subscriptions indiscriminately; overlapping stories can create duplicate noise. Keep the channel spoiler-gated because official headlines and images may reveal new content.

You can separately add selected YouTube or available Twitch subscriptions for members who consent to being featured. Put those in the optional streams channel, not the newcomer welcome area, and state the stream’s spoiler level.

Test: confirm a real new item reaches the correct channel and that a member without the news role cannot see it. Keep the official Lodestone news page bookmarked as the direct reference.

13. Keep FC Projects and Crafting Organized

Use #company-notices for the FC’s operating information: who handles company actions, where the estate is, how chest access works, and whom to contact about housing or membership. Square Enix’s Free Company overview describes the underlying company systems; Discord documentation does not change those in-game controls.

Use #company-projects for workshop materials, furnishing plans, garden coordination, or other agreed projects. Give each project an owner, a current list, and a completion state. Keep donations voluntary and record transfers manually rather than implying the bot can inspect the company chest.

For ordinary crafting requests, start with a consistent format: item, quantity, required quality, materials already supplied, deadline, and handoff World. Link an appropriate planning list rather than pasting hundreds of material lines into chat.

Teamcraft’s browser lists can complement this workflow. Universalis can provide crowdsourced market references, but check update times and verify the actual in-game listing before treating a price as current. These are separate tools, not automatic YourBot integrations or Square Enix endorsements.

14. Use Analytics Without Turning Membership Into a Score

Open Analytics, exclude bots, set the display time zone, and review channel and role exclusions. Keep recruitment, tickets, staff discussions, and automated feeds out of general participation comparisons where appropriate.

Begin with questions you can act on: Are newcomers finding help? Which evenings support optional events? Do several quiet channels need merging? Are text conversations declining because more people are using voice?

YourBot’s privacy documentation distinguishes activity metadata from content. Voice-session measurement does not record audio. Other features, including ticket transcripts and moderation context, may store content for their own purposes; explain enabled services and retention to members.

Discord activity is not raid attendance, combat performance, MSQ progress, or loyalty. Keep a static’s attendance record separate and avoid automatically removing FC access because someone stopped posting. A person may be playing quietly, taking a subscription break, or contributing in ways Discord does not measure.

Test: check expected message and voice activity, exclusions, dashboard access, and what member-facing statistics commands reveal before announcing the system.

15. Use Giveaways Only for Optional Celebrations

When ready, enable Giveaways, choose the optional destination, and configure the title, entry method, prize, winner count, and schedule. Check the displayed server time zone rather than assuming it behaves like Beacon’s browser-local field.

For a simple celebration, choose equal chances and leave role and booster bonuses at zero. State eligibility, the closing time, and how the prize will be delivered. Verify that any in-game item can actually be transferred; Free Trial trading restrictions may affect delivery.

Never use this as a substitute for Savage loot rules, company-chest permissions, or a static’s agreed reward allocation. The service manages the Discord giveaway, not an in-game loot roll or item transfer.

Test: use a clearly labeled test draw with no valuable prize, check entry and winner behavior, and confirm who is responsible for delivery.

16. Build a Custom Crafting Request Board Only When Needed

Start with the existing services and an organized crafting channel. Browse the marketplace before commissioning something new, checking the listing, capabilities, maintenance, and price.

A sensible custom feature is an FC crafting request board: a persistent queue where somebody claims a request, tracks its status, and confirms a manual handoff. This is a proposed Plugin Builder project—not a claim that a built-in FFXIV crafting integration already exists.

Use a deliberately narrow specification:

Create a YourBot SDK plugin called fc_craft_board for manually entered
FFXIV crafting and gathering requests. This is a Discord coordination tool,
not a game integration.

Allow configured member roles to create a request with item name, quantity,
required quality, materials supplied, optional deadline, and handoff World.
Allow configured crafter roles to claim an open request. Only the requester,
assigned crafter, or configured staff may update it. Use Open, Claimed,
Ready, Completed, and Cancelled states. Limit each requester to three
unfinished requests. Let staff correct mistakes and delete records.

Provide commands or buttons to create, view, claim, update, and cancel.
Reject two people claiming the same request, and handle repeated button
clicks safely. Keep data isolated per server and enforce authorization in
handlers, not just through hidden buttons.

Provide a member-only board and staff-only settings. Staff choose allowed
member/crafter roles and the board channel. No anonymous public dashboard.
Show understandable errors for missing roles, deleted channels, invalid
quantities, or an unavailable operation. Keep completion and handoff manual.

Do not request Square Enix credentials, inspect game memory, read inventories,
move items or gil, infer market prices, or change FC membership. Do not scan
ordinary chat. No external API calls or scheduled background jobs in version
one. Use supported SDK storage and interactions. Explain any unsupported
requirement in the plan rather than silently replacing it.

Open the Plugin Builder, review the current credit quote, and ask for a plan first. Confirm commands, storage, dashboard access, and capabilities before approving the build. Review the generated source and validator findings, then create the plugin and test-install a committed version on a server you manage.

Test a normal request, unauthorized update, duplicate claim, cancellation, and missing configuration. A passed validator does not prove the business rules are correct, and a temporary development install is not the final ongoing deployment.

A developer can continue in VS Code using the YourBot SDK quick start, local development tools, and validation. The result remains a YourBot plugin, not an unrestricted standalone bot. Complete the appropriate installation or publication workflow before members depend on it.

Launch Gradually, and Migrate Existing Servers Carefully

For a new FC Discord, use the first week to validate the experience rather than to activate every possible feature.

First, test access and onboarding. Have a non-admin newcomer, an FC member, and an outside static member check their actual views. Submit an application and complete a private staff conversation.

Next, run one modest activity. A dungeon-help session or social evening exposes confusing signups without risking an important progression night. Test the temporary voice lifecycle and the news destination.

Then, establish the routine. Publish the next events, confirm the static roster, review moderation detections, and adjust notification frequency. Ask a returning player and a console player where they became confused.

An established FC should keep useful channel history and migrate one function at a time. Start Your Server can help plan the replacement structure, but do not assume third-party schedules, warning histories, transcripts, or statistics are automatically imported.

Preserve necessary records, stage new panels privately, and give each action one owner. Disable the old welcome automation before enabling its replacement. Avoid duplicate feed subscriptions, event reminders, giveaway draws, or punitive moderation. Retire an old bot only after the new workflow passes member and staff tests.

Keep a short staff runbook with the dashboard entry point, responsibility for each service, emergency contact, access policy, and manual fallback for events or moderation.

Frequently Asked Questions

Can an FFXIV static use this without a Free Company?

Yes. Keep the community, static, event, group, and voice workflows, and omit FC-only projects and membership assumptions. Recruit for the team’s activity and schedule rather than requiring an in-game company invitation.

Does YourBot automatically verify Lodestone characters or synchronize FC ranks?

The setup described here does not do that. A verification button grants a Discord role, not proof of character ownership. Treat profile links as supporting information and perform the required checks yourself. A dedicated integration would need its own documented capabilities, authorization, and testing.

Do members need FFXIV client plugins?

No. The workflows described here operate through Discord and YourBot’s dashboard. The custom example is a YourBot SDK plugin, not a modification of the FFXIV game client, and it does not require combat capture or game automation.

Build a Community People Can Actually Use

The best FFXIV FC Discord is not the one with the most channels or the most demanding activity requirements. It makes joining understandable, keeps the story safe, separates company membership from static commitments, and helps people spend more time enjoying activities together.

Use Start Your Server for the foundation, configure the built-in services around real member journeys, and test every permission-sensitive workflow. Add a marketplace or Plugin Builder feature only when a specific recurring problem remains. Let the tools reduce the work of running the FC—not turn the FC into more work for its members.