Players

One person can have several identity layers

Player documentation separates the platform account, the alliance-local player record, and the linked game profile so that synchronization and lifecycle actions are predictable.

players

Search tasks, concepts, states, and troubleshooting

I need to...

Search Kingshot Events documentation

Add or update a playerLink a game profileRecord event resultsImport a screenshotCorrect imported rowsReview analyticsConfigure reward rulesApply for a Castle PositionReview applicantsBuild and publish a scheduleRead a scoped articleCreate and publish an articleCreate a Reading Verification sessionUse a saved Lab profileOptimize Hero GearConfigure a Bear Trap rallyUnderstand premium accessRestore deleted information

Product areaAll product areasCastle PositionsSimulations and OptimizationsSubscriptions and UsageGetting StartedAccounts and AccessScopes and CommunitiesPlayersEvents and ResultsImports and Data EntryAnalytics and RewardsKnowledge HubTroubleshootingRole JourneysPlatform LifecyclesOverviewUpdatesRole or audienceAll rolesPlayer or memberAlliance leaderKingdom managerMinister of JusticeKnowledge author or reviewerReading-session managerContent typeAll content typesOverviewHow it worksTask guideAlgorithm and decision logicStatus referenceTroubleshootingRole journeyExperience levelAll levelsBeginnerIntermediateAdvanced

6 highest-relevance guides shown

PlayersPlayers Player documentation separates the platform account, the alliance-local player record, and the linked game profile so that synchronization and lifecycle actions are predictable.Matched in: IntroductionPlayersPlayers and roster managersHow it worksAdvancedProfile, Identity, Activity, and HistoryOne account can identify a person using the platform, while the player record preserves the in-game identity, alliance history, event results, and calculated status. Profile, Identity, Activity, and History The history timeline records the Matched in: IntroductionPlayersPlayers and roster managersAlgorithm and decision logicAdvancedPlayer Directory and ProfilesPlayer Directory and Profiles The Players page is the scoped roster and the safest starting point before adding, linking, editing, removing, or restoring a player. Each row represents one shared player identity in a kingdom. An account profMatched in: IntroductionPlayersMembers and managersHow it worksIntermediateAdding and Updating PlayersAdding and Updating Players Authorized managers can add and edit shared player records from Players . The form is hidden from viewers who can read the directory but cannot manage players.Matched in: IntroductionPlayersAlliance and kingdom managersTask guideIntermediatePlayer Linking and SynchronizationPlayer Linking and Synchronization Linking and synchronization solve different problems. Linking connects a signed-in account to one existing shared player identity. Synchronization refreshes supported public Kingshot profile values for a pMatched in: IntroductionPlayersPlayers and managersHow it worksIntermediateActivity, Attributes, Removal, and RestoreActivity, Attributes, Removal, and Restore A player can leave an alliance without leaving the kingdom, and can be hidden without erasing historical event records. Choose the action that matches the real-world change.Matched in: IntroductionPlayersPlayers and managersHow it worksIntermediate

Feature map

Player information and lifecycle. Linking controls synchronization; Kick, Delete, and Restore are separate branches.

Accessible summary: A player is found and identified before link precedence and history are interpreted. Membership changes, kick, soft deletion, and restoration have different effects.

What each guide answers

• Directory and profiles covers filters, columns, duplicate names, opening a profile, and interpreting empty results.
• Profile, identity, activity, and history is the deep reference for account, local record, game profile, external ID, nickname history, activity calculation, and lifecycle states.
• Player linking and synchronization explains which values can synchronize, which remain manual, and how conflicts are reviewed.
• Adding and updating players covers field validation, alliance context, new records, and safe correction.
• Activity, attributes, removal, and restore distinguishes calculated state, manual override, Kick, Delete, and recovery.

Decision order

Identify a player by stable external ID when it exists; names are display values and may collide or change. Resolve synchronized fields from the verified game profile, preserve locally controlled fields and approved overrides, then calculate derived views from saved history. A manual activity override takes precedence while present. Removing it returns control to automatic calculation; the documentation does not invent numeric thresholds that the current product does not expose.

Kick affects alliance membership. Delete is a soft-delete path for an eligible record and removes it from normal active views. Restore returns an eligible deleted record while preserving user-visible history. A manager should not create a replacement player simply because the old record is hidden or has a former nickname.

Worked example

Starting situation: Two players display the nickname "Nova." One has a linked external ID and recent event history; the other is an unlinked local record. Input: A screenshot row named Nova. Rules: Name equality alone is not sufficient when candidates are ambiguous. Branch: Automatic matching stops for human review. State: The import row remains unresolved rather than updating either player. Output: A reviewer selects the correct player using alliance context, external ID where available, and history. Next action: Apply the reviewed row; do not merge identities only because their nicknames match.

Common mistakes

• Creating a second player after a nickname change fragments history.
• Treating Kick as Delete hides the membership problem and may affect downstream expectations.
• Editing a synchronized value without checking its source can make the next refresh appear to "undo" work.
• Interpreting missing activity data as Inactive is unsafe; use the documented missing-data state and history.
• Moving a player does not rewrite historical event scope. Review reports using the event and alliance context in which records were saved.

For recovery, record the player display name, external ID if visible, active alliance, operation attempted, resulting state, and source record or import involved. Do not include private credentials.