Skip to content
Imports and Data EntryContributors and import reviewersAdvancedProduct guide

Imports and Data Entry

Extraction proposes; reviewers decide

Imports accelerate transcription, but extracted text is not authoritative. Event context, normalization, matching, duplicate checks, and review turn a file into eligible product records.
imports

Search tasks, concepts, states, and troubleshooting

I need to...

6 highest-relevance guides shown

Imports and Data EntryImports and Data Entry Imports accelerate transcription, but extracted text is not authoritative. Event context, normalization, matching, duplicate checks, and review turn a file into eligible product records.Matched in: IntroductionImports and Data EntryContributors and import reviewersTask guideAdvancedScreenshot Reconciliation and Row DecisionsScreenshot Reconciliation and Row Decisions An unknown player decision must be resolved explicitly; an unrecognized name is not silently attached to the nearest player. The processor extracts candidates; it does not write trusted results. EMatched in: IntroductionImports and Data EntryImport contributors and reviewersAlgorithm and decision logicAdvancedScreenshot ImportScreenshot Import Screenshot import converts a supported leaderboard or roster image into proposed rows. Processing is assisted data entry: no extracted row is trustworthy until a person checks the context, match, values, and date.Matched in: IntroductionImports and Data EntryAuthorized contributors and managersTask guideIntermediateReviewing and Applying Imported DataReviewing and Applying Imported Data Import Review is the decision point between extracted text and product records. Acceptance can create or update player and result data in the selected scope, so review the screenshot and context beside tMatched in: IntroductionImports and Data EntryContributors and alliance managersTask guideIntermediateDuplicate, Date, Overwrite, and Restore RulesDuplicate, Date, Overwrite, and Restore Rules Import safety depends on three identities: the player, the event or session, and the event date. A similar name is not enough to prove a duplicate, and a second screenshot is not always a separaMatched in: IntroductionImports and Data EntryContributors and managersTask guideIntermediateImport TroubleshootingImport TroubleshootingMatched in: IntroductionImports and Data EntryImport contributorsTask guideIntermediate

Reconciliation pipeline

Import reconciliation. Ambiguity and conflicts branch to human review; applying is distinct from accepting a row.

Accessible summary: A file receives scope, event, and date context before extraction. Rows are normalized, matched, checked for duplicates and validation, reviewed, accepted or rejected, then applied as a traceable batch.

Choose the right entry path

Use manual entry for a small number of known rows or when the source cannot be parsed reliably. Use screenshot import for a supported ranking image. Use structured input only for the supported format and fields described by spreadsheet and structured input. Every path still requires correct scope, event, date, and player identity.

The processor or provider may affect extraction availability and diagnostic messages, but it does not change the meaning of accepted records. Normalization removes supported presentational differences; it must not be treated as proof that two similar names identify the same player. Ambiguous names, missing values, unsupported formats, and low-confidence extraction remain review work.

Row and batch states

Rows can be extracted, matched, unresolved, invalid, accepted, rejected, applied, or affected by rollback depending on the workflow. A reviewer correction changes the candidate row; it does not modify a game account. Apply All applies one supported choice across eligible rows and must not bypass invalid, ambiguous, duplicate, locked, or rejected states. Autosave preserves review progress where shown; it is not the same as applying the batch.

Worked example: partial extraction

Starting situation: A ranking screenshot yields eight readable names, two uncertain names, and one unreadable score. Inputs: Correct alliance, event, and date. Rules: Clear rows continue to matching; ambiguous or invalid rows cannot be silently applied. Branch: Eight rows become reviewable matches, two require player selection, and one requires score correction or rejection. State: The batch remains partially reviewed. Output: The reviewer corrects one name, rejects the unreadable row, accepts the rest, then applies the eligible subset. Next action: Compare event history with the source image and retain the batch history for later recovery.

Common mistakes and recovery

  • A duplicate screenshot can produce overlapping proposals; inspect event, date, player, and existing result identity before applying.
  • If the wrong context was chosen, reprocess with correct context before apply. After apply, use batch history and the supported rollback or correction path.
  • Deleting an import is not the same as rolling back records already created from it.
  • Restoring a deleted import does not necessarily reapply rows; inspect its state and linked records.
  • Partial provider failure may leave a recoverable import with diagnostics. Do not repeatedly upload the same file until you know whether a batch was created.

Continue to row states and decisions for exact review order and import troubleshooting for symptom-based recovery.

Independent community documentation. Not affiliated with or endorsed by Kingshot or its publisher.