Theme
Getting Started
Begin with the right identity and community
Kingshot Events is scope-aware. A useful first session therefore confirms who you are, which game player record is linked to you, and which kingdom or alliance is active before opening data-entry or management tools.
getting startedSearch tasks, concepts, states, and troubleshooting
I need to...
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
4 highest-relevance guides shown
Getting StartedGetting Started Kingshot Events is scope-aware. A useful first session therefore confirms who you are, which game player record is linked to you, and which kingdom or alliance is active before opening data-entry or management tools.Matched in: IntroductionYour First Visit, Registration, and LoginYour First Visit, Registration, and Login The public home explains the available product areas. Public Knowledge articles, Castle Position application routes, and enabled Lab modules can work without a signed-in session. Shared rosters, eveMatched in: IntroductionAccount, Profile, and Player LinkAccount, Profile, and Player Link Your account controls sign-in and personal settings. A player link connects that account to one shared kingdom player so personal analytics, rewards, appointments, and reading assignments can resolve the coMatched in: IntroductionChoosing Scope and Understanding AccessChoosing Scope and Understanding Access Access answers two questions: what may this account do, and in which kingdom or alliance may it do it? Navigation and actions reflect both answers plus current module and subscription availability.Matched in: Introduction
What this category helps you do
Start here to register, sign in, understand an approval state, connect an account to a game player, select an available community, and recognize why a navigation item may be absent. Registration creates a platform identity. It does not automatically create management authority, a subscription, or a verified player link.
First-session decision path. Identity, link, and scope are separate gates, so resolving one does not imply the others.
Accessible summary: The path branches for registration, player linking, and scope availability. A user proceeds to a real task only after the applicable gates are satisfied.
Recommended reading order
- Your first visit, registration, and login explains account states, password handling, and approval.
- Account, profile, and player link separates the user account from the local player and linked game profile.
- Choosing scope and understanding access explains why the visible workspace changes.
- Continue by role: player or member, alliance leader, or kingdom manager.
A ten-minute first session
After signing in, open the account area and verify the displayed identity. If a player link is shown, compare its external player ID and current nickname with the intended game account; names alone are not reliable identifiers. Open the scope switcher, select a kingdom or alliance you actually belong to or manage, then open one existing record before changing anything. A member might inspect personal Analytics or a published Knowledge article. A manager might open the player directory or an event history view.
The first success signal depends on the task: a read-only view loads data for the chosen scope, an editable form shows a saved state, a review workflow shows the new status, or a publication workflow produces a distinct published version. Do not assume that leaving a form means it saved.
Worked example
Starting situation: Mira has an approved account and manages an alliance, but the dashboard opens without alliance controls. Checks: She confirms the linked player, opens the scope switcher, and sees that her personal context is active. Branch: She selects the alliance assignment. State change: The active scope changes; her account and player link do not. Output: Alliance-scoped directory and event actions appear. Reason: Role, assignment, active scope, and feature availability now resolve together. Next action: She opens the player directory and checks its alliance label before editing.
Common mistakes and recovery
- If an expected action is missing, check identity, active scope, assignment or membership, feature availability, and effective plan in that order.
- If a player name looks wrong, inspect the linked external ID and synchronization history before creating a second player.
- If a page is read-only, a shared Analytics grant may permit viewing without edit authority.
- If work does not show a saved confirmation, remain on the page and use the mechanism-specific recovery guide.
Related product areas
Scopes and Communities explains context resolution. Accounts and Access explains roles and approvals. Troubleshooting begins from the visible symptom.