Theme
Working 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.
Safe management practice
Use filters to narrow the working set, verify the source alliance before editing a player, and publish only after reviewing the final schedule or result set. A kingdom-level assignment does not make every platform-administration function public or appropriate.
Ministers of Justice should use the Castle Position areas relevant to review and scheduling. Other kingdom settings appear only to users with the corresponding assignment.
Related guides
Practical depth
Coordinate without erasing alliance context
Use kingdom scope for comparison and shared planning, then follow corrections back to the alliance source. Review missing data and filters before drawing conclusions across communities.
Purpose, example, and limits
Kingdom work coordinates cross-alliance visibility, grants, shared rules, and Castle scheduling without erasing alliance ownership. Example: A kingdom total is low because one alliance batch is unapplied. The manager traces the total to that alliance, routes the correction to its authorized owner, then verifies recalculation with unchanged filters. The aggregate is output, not an edit surface. Kingdom responsibility cannot bypass an alliance lock, private Knowledge space, or quota. Report kingdom, alliance, workflow, source state, filters, and expected outcome.
Limitations include missing alliance evidence, read-only grants, cycle state, allocation, and immutable publications. Troubleshooting follows the owning alliance, event batch, application, schedule version, article revision, or grant rather than changing an aggregate. The kingdom role cannot reveal private platform-administration procedures.