Why start with the staff role instead of the permission list?
Write down the job first: welcoming players, handling reports, reviewing moderation decisions or maintaining resources. A title such as admin is too vague to decide access. For each job, name the person responsible, the actions they may take alone and the situations they must escalate. This makes expectations explainable to staff and players.
This is evergreen operational guidance checked on 12 September 2026, not a new txAdmin release announcement. It is AI-assisted editorial content by FiveMCoach. The role examples below are our proposed policy, not official txAdmin presets.
txAdmin includes an admin permission system and action logging. Its controls cover both player moderation and server operations. That is why access deserves a deliberate handoff rather than a copied account. See the official txAdmin overview.
Which permissions deserve a separate decision?
The official permission reference distinguishes console.view from console.write, and gives server start, stop and restart control to control.server. It lists manage.admins for changing admin accounts and all_permissions as unrestricted access. Permissions can be edited in Admin Manager by the Master admin or an account with the appropriate management permission. Read the txAdmin permission reference.
Use those distinctions when reviewing a request. If the task is to describe an error to a developer, ask whether console viewing is sufficient. If the task is to handle a player report, ask what moderation action is justified and who reviews it. Do not add console execution simply because it saves an escalation message.
How do you give a new staff member a clear handoff?
- Agree one written role with the member. Include examples of what they can resolve and what they must pass on.
- Have the authorized account manager review the current permission options in the installed txAdmin version. Select only the actions justified by that role.
- Record the account, approved permissions, reason, approver and next review date in a private team record. Do not put credentials or player identifiers in a public document.
- Explain how to request additional access. A request should name the blocked task, not simply ask for the same access as the owner.
- Arrange a supervised rehearsal before independent use.
Do not treat a txAdmin review as a complete access audit. Separately check the person's hosting, repository, Discord and resource-specific access. Avoid assuming that a change in one system changes permissions elsewhere.
What should the rehearsal actually prove?
Use a staging server and consenting test participants for actions that could interrupt play. The member should demonstrate one approved task, identify where its action record can be reviewed, and explain an escalation case. Check that unapproved controls are unavailable through ordinary use of the interface. Do not probe private endpoints or test a kick, ban or restart against real unsuspecting players.
A useful rehearsal note reads: intended action, expected result, observed result, reviewer and follow-up. For example, a helper may need to contact a test player, while a maintenance operator needs an agreed resource-control procedure. The owner should be able to explain why their permissions differ without treating one person as less valued.
What if the wrong access was granted?
Ask the authorized account manager to remove the unnecessary grant and recheck the member's effective access. Review relevant action records and establish what happened before deciding whether any correction is needed. Preserve the remaining legitimate access when appropriate. Avoid a hurried blanket change that leaves nobody responsible for recovery.
For a departing member, use the same record to review access across each system, confirm the removals and transfer unfinished responsibilities. Assign someone to own follow-up. Do not equate a role name disappearing from Discord with a completed technical handoff.
How does this support community trust?
Write rules that staff can apply consistently, explain decisions in a way players can understand, and provide a route for review. Keep private evidence private. Player feedback can reveal unclear rules or repeated confusion; consider that feedback without turning every moderation decision into a popularity vote. Trust requires judgment and kept commitments as well as access controls.
Use the server launch playbook for broader readiness and the server fix-order guide for prioritizing technical work. If you need help organizing the wider project, explore the server-owner path. This article does not inspect your server, test its permissions or certify your staff process.