Events and Results

Keep configuration, occurrence, and evidence separate

An event name describes a configured kind of activity. An event instance describes one occurrence in a scope. Results and record batches provide the player evidence attached to that occurrence.

events

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

9 highest-relevance guides shown

Events and ResultsEvents and Results An event name describes a configured kind of activity. An event instance describes one occurrence in a scope. Results and record batches provide the player evidence attached to that occurrence.Matched in: IntroductionEvents and ResultsContributors and event reviewersHow it worksAdvancedEvent Instances, Record Batches, and CorrectionsEvent Instances, Record Batches, and Corrections An event template defines reusable behavior: scope, duration, stages, score-entry mode, required fields, activity participation, reward participation, and score rules. An instance is one dateMatched in: IntroductionEvents and ResultsResult contributors and reviewersAlgorithm and decision logicAdvancedPreparation and KvK TrackingPreparation and KvK Tracking Preparation and KvK workspaces track a bounded session. They connect before and after power evidence, reminder timing, reviewed rows, and a growth report. Do not mix sessions merely because they concern the sameMatched in: IntroductionEvents and ResultsKingdom event managers and reviewersHow it worksAdvancedEvent Proposals, Templates, and SettingsEvent Proposals, Templates, and Settings An event proposal suggests a reusable definition. A template describes structure and result behavior. An instance schedules that definition for a real period. A record batch supplies observations. ThMatched in: IntroductionEvents and ResultsEvent contributors and settings managersHow it worksAdvancedEvent Templates, Instances, and ResultsEvent Templates, Instances, and Results Kingshot Events separates a reusable event definition from each dated occurrence. - An event template defines the name, category, duration pattern, score-entry mode, stages, participation support, anaMatched in: IntroductionEvents and ResultsPlayers and managersHow it worksIntermediateParticipation, Scores, Stages, and Cumulative EventsParticipation, Scores, Stages, and Cumulative Events The value entered for a player must match the template's event mode. A number copied from the right screenshot into the wrong mode can still save and later produce misleading analytics.Matched in: IntroductionEvents and ResultsContributors and managersHow it worksIntermediateEntering Results ManuallyEntering Results Manually Manual entry is best for a small number of verified results or a targeted correction. Use screenshot or spreadsheet import for a full leaderboard, but keep the same review discipline.Matched in: IntroductionEvents and ResultsAuthorized contributorsTask guideIntermediateReviewing Results and Event HistoryReviewing Results and Event History Use the dated event instance as the main record of what happened. Player history answers which events affected one player, while import and record-batch history explain how a set of rows entered the platfMatched in: IntroductionEvents and ResultsPlayers and managersHow it worksIntermediateEvent-Specific Behavior and Template ChangesEvent-Specific Behavior and Template Changes The seven default templates give new scopes useful starting behavior, but authorized managers can adjust them. The active template and instance labels are the source of truth for entry.Matched in: IntroductionEvents and ResultsPlayers and managersHow it worksIntermediate

Product model

Event data flow. Templates configure meaning; instances establish occurrence identity; batches preserve entry provenance; locks change the correction path.

Accessible summary: A template creates an event instance with scope and date context. Manual or imported batches produce results used downstream. An unlocked instance can be corrected by an authorized user; a locked one requires the applicable review path.

Important terminology and identity

A default event starts from product-provided behavior. A custom event is community-configured. A proposal is a requested configuration change until reviewed. An instance is not the template itself. Its identity includes the configured event, its alliance or kingdom context, and its occurrence information. A stage or position adds meaning where the event supports it. A record batch groups one save or applied import so users can trace where results came from.

Two uploads on the same date are not automatically harmless duplicates. The platform compares event, scope, date, player, result kind, and existing batch context. The review path may flag overlap, request overwrite or correction intent, or keep rows unresolved. Creating a second instance simply to bypass an existing locked or same-date occurrence fragments history.

Main workflows

1. Templates, instances, and results establishes the model and event modes.
2. Instances, record batches, and corrections gives the complete identity and lock decision logic.
3. Participation, scores, stages, and cumulative events explains supported result shapes.
4. Enter data through manual entry or imports.
5. Use review and history before interpreting Analytics and Rewards.

Worked example: same date twice

Starting situation: Alliance Red already has a score batch for a configured event on 1 August. A contributor uploads another screenshot for that event and date. Inputs: Same scope, event, date, and several overlapping players. Rules: Existing identity and player overlap are checked before apply. Branch: Overlapping rows are treated as possible duplicates or corrections; genuinely new eligible rows can remain reviewable. State: Nothing should silently create a second authoritative result for an ambiguous row. Output: The reviewer chooses reject, correction or supported overwrite behavior row by row or batch-wide where allowed. Next action: Apply only after the batch preview reflects intent, then verify event history and recalculated downstream views.

Mistakes, recovery, and limitations

• If the wrong date or scope was selected, stop before apply; after save, correct through the source batch or event history.
• If an event is locked, do not manufacture a replacement event. Use the authorized correction or unlock workflow.
• If Analytics is empty, verify saved results, eligibility, filters, date boundaries, event selection, and active scope.
• Template changes do not necessarily rewrite historical instances. Interpret an old result using its stored occurrence context.

The platform can enforce identity and workflow rules, but it cannot determine whether a screenshot depicts the intended occurrence without correct human context.