Scopes and Communities

Every record has a community context

Scopes keep one kingdom or alliance from accidentally reading or changing another community's records. The active scope is a working context, not a new permission.

scopes and communities

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

Scopes and CommunitiesScopes and Communities Scopes keep one kingdom or alliance from accidentally reading or changing another community's records. The active scope is a working context, not a new permission.Matched in: IntroductionScopes and CommunitiesMembers and community managersHow it worksAdvancedHierarchy and Scope SwitchingScope decides which community owns a record. Role decides what you may do inside that scope. Analytics grants can add read-only visibility without adding management access. Hierarchy and Scope Switching Scope switching changes the active coMatched in: IntroductionScopes and CommunitiesMembers, alliance leaders, and kingdom managersHow it worksAdvancedAlliance Hub and ManagementAlliance Hub and Management The Alliance Hub gathers the current alliance's member, event, preparation, resource, and announcement context. It does not turn alliance access into kingdom-wide authority. The hierarchy remains Server → KingdomMatched in: IntroductionScopes and CommunitiesAlliance members and managersHow it worksAdvancedHow Scopes WorkHow Scopes Work A scope is the kingdom or alliance context in which a task is performed. The same account can have different responsibilities in different scopes.Matched in: IntroductionScopes and CommunitiesAll signed-in usersHow it worksIntermediateWorking Inside an AllianceWorking Inside an Alliance Alliance work brings together the roster, manual input, imports, event results, reports, and selected analytics. Open My Alliance or the assigned alliance management view when available.Matched in: IntroductionScopes and CommunitiesAlliance leaders and co-leadersHow it worksIntermediateWorking Inside a KingdomWorking Inside a Kingdom Kingdom views support community-wide review where the assigned role allows it. Typical work includes checking alliances, reviewing analytics, coordinating events and rewards, and managing Castle Positions.Matched in: IntroductionScopes and CommunitiesKings, kingdom managers, and Ministers of JusticeHow it worksIntermediate

Feature map

Community hierarchy. Player and alliance records remain attached to their kingdom lineage while kingdom-wide workflows can aggregate permitted child data.

Accessible summary: A server contains kingdoms, kingdoms contain alliances, and alliances contain player records. Some workflows are kingdom-scoped while others remain alliance-scoped.

The user-facing term server may be used as an alias for a game kingdom in conversation, but the product's scope labels are authoritative on each page. Alliance is the community membership layer. Active scope is the currently selected kingdom or alliance. Assignment describes authorized management. Membership describes belonging. Neither should be substituted for the other.

How the mechanisms relate

The scope switcher offers contexts derived from the signed-in identity and its current memberships, assignments, and permitted roles. Selecting one changes the records queried and the actions evaluated. It does not move players, modify roles, accept grants, or copy records. A player moving alliances is a lifecycle operation; a manager viewing a different alliance is a context change.

Kingdom-level Analytics can aggregate eligible results from child alliances. Alliance Analytics remains bounded to its alliance. A shared Analytics grant can expose a read-only kingdom view to another eligible user without making every underlying result editable. Castle Position cycles are kingdom workflows. Knowledge articles can be public, authenticated, kingdom-scoped, alliance-scoped, or premium, so both article state and viewer scope matter.

Main workflows and reading order

1. Read Hierarchy and Scope Switching for the complete resolution order and examples.
2. Use Membership and Management to distinguish belonging, delegated work, and ownership.
3. Use Cross-Scope Visibility before interpreting kingdom totals, grants, or shared content.
4. Continue to Working Inside an Alliance or Working Inside a Kingdom.

Worked example

Starting situation: Talia belongs to Alliance Red and has a kingdom role used for Castle scheduling. Input: She selects Alliance Red. Rules: Alliance membership permits member views; the active alliance bounds roster and event records; her kingdom responsibility remains on the account but applies only on qualifying kingdom workflows. Output: Alliance records appear, while the Castle planner asks for or returns to kingdom context. Next action: She switches to the kingdom before reviewing applicants. No player membership changes.

Common mistakes and recovery

• If data looks empty, confirm the scope label, filters, date boundary, and whether source records exist in that same scope.
• If an action disappears after switching, the new scope may not match the assignment even though the page remains visible.
• If a player changes alliance, use the player-management lifecycle instead of creating a duplicate record.
• If shared data is read-only, correct the source in its owning scope or contact that scope's authorized manager.

Scope history and selection cannot guarantee that a user understands the organizational meaning of a record. Before any save, verify the visible kingdom or alliance label and the affected entity.