Floodgate Account Linking: Check Data and Permissions Before Release
Before enabling or changing Floodgate account linking on an established Minecraft server, record which identity owns each player's data and rehearse the change with controlled accounts. Require checks for inventory, permissions and every important plugin. A successful login alone does not establish that the community is ready.
Geyser's linking documentation explains that linked players use their Java account's progress, including inventory and location. Their separate Bedrock progress becomes accessible again after unlinking. Do not plan the release as an automatic merger of two histories.
This guide is for community owners and teams commissioning crossplay integrations. It proposes an acceptance procedure; it does not report tests run on a Mineando deployment or certify compatibility with your plugins.
Decide what players should experience
Write the intended outcome before changing configuration. Should a person use one existing Java profile from either edition? Does your community want to support independent profiles? Who will help a player who already has valuable progress on both?
Use a concrete example. A participant has built a house with their Bedrock identity and has a different inventory on Java. Your release sheet must say what they should see after linking, which existing data needs attention and who may authorize a transfer. “Crossplay works” is too broad to settle that question.
Record whether the installation uses global linking, local linking or both. Floodgate documents that local entries override global entries. Include that precedence in your investigation if a player's result differs between environments. Do not assume a test server reproduces production simply because both have Floodgate installed.
Tell participants what will change before asking them to link. Do not request their Microsoft password or recovery codes. Account control should be demonstrated through the supported linking flow, not by giving staff access to personal credentials.
Build an identity and data register
For each controlled test account, capture the edition, visible name, UUID observed by the server, linking state and route used to connect. A UUID is the player identifier your team should compare alongside the displayed name. Use server records; the Floodgate FAQ identifies logs as a way to obtain Bedrock player UUIDs.
Then make a small register for your actual stack:
| Data or access | Question the owner must answer | Evidence to retain |
|---|---|---|
| Inventory and ender chest | Which profile should be active in each state? | Controlled before/after contents |
| Permissions and staff access | Which account is authorized for each role? | Verified identity and effective permissions |
| Claims, homes and economy | How does each installed plugin identify its owner? | Plugin-specific lookup and expected result |
| Website or event integration | Which identifier does the integration store? | Test record and documented mapping |
These are review questions, not a claim that every plugin stores data in the same way. Ask the developer to identify the storage key and supported migration method for each component. If that answer is unknown, keep it as an unresolved requirement.
Avoid “repairing” the situation by copying player files, editing database rows or granting a rank to a similar-looking name. First establish the relationship between the old and intended identities. Any transfer needs its own scoped procedure and a recoverable starting point.
Prepare a rehearsal that cannot change live progress
Use an isolated copy with the relevant software versions and a deliberate test dataset. Prevent it from writing to production plugin databases or triggering live rewards and integrations. The backup restoration rehearsal guide covers checking recovery in isolation.
Use accounts controlled by the team. If you test global linking, remember that the link is not confined to this rehearsal server; plan changes only for those accounts and document their initial state. Prefer a separate test setup for experiments with local records, and clearly note any difference from production.
Seed unmistakable but low-value test data: different inventory contents, a test home, an ordinary permission and a staff permission that the participant should never receive. Record the expected result before each login. This makes a mistaken identity easier to notice than an empty fresh profile would.
Run the same journeys with every essential plugin
The following matrix describes tests to perform, not measured results. Add your actual plugin names, software builds, timestamps and observations.
| Journey | Required observation |
|---|---|
| Java login before the change | Existing Java data and permissions match the baseline |
| Unlinked Bedrock login | Its separate baseline is identified and recorded |
| Linked Bedrock login | The intended Java profile is active; plugin results match the agreed mapping |
| Reconnect and move between configured backends | Identity and expected per-server data remain consistent |
| Unlink the controlled test pair | The expected separate profile returns; plugin state is checked again |
| Repeat with a non-staff participant | No unintended staff access or extra reward appears |
Where a plugin issues a first-join reward, assigns ownership or synchronizes a website record, add a specific check for duplicate actions and wrong recipients. This is a proposed acceptance condition for your integration, not an assertion that Floodgate causes those failures.
If you commission custom code, ask how it detects Floodgate players and resolves linked identities. The Floodgate API exposes player detection and linking information. Require the developer to document where that information is available in your topology. Guessing from a name prefix should not be the integration's identity contract.
Stop on unexplained differences
An empty inventory is a finding to investigate, not permission to overwrite another profile. Unexpected ownership, extra rewards or elevated access should pause the release. Preserve the before/after evidence and identify which component made the decision.
Do not rename prefixes as an emergency workaround: the Floodgate FAQ warns that removing the prefix can create duplicate-name problems. Treat a naming change as another change requiring review.
Separate three operations in the incident plan: reversing linking, reversing an approved data transfer and restoring a backup. Do not assume the first reverses the other two. Define who may perform each operation and how new progress will be reconciled if players have already returned.
Release only when the identity register, plugin matrix, participant instructions and recovery responsibilities are complete. If you need help adapting plugins or connecting a website to these identities, include those deliverables in a Minecraft development project. Mineando scopes and quotes paid projects individually; ongoing support is agreed separately.
