> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rodyne.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Review rank requests
> Request, approve, execute, and verify Roblox rank changes.
Rank requests turn a proposed member change into a permission-checked, approval-aware, provider-verified workflow.
## Create a request
From **Community Management → Members** or **Rank requests**:
1. Select the exact member.
2. Confirm the expected current mapped role.
3. Choose the target mapping.
4. Enter a clear reason.
5. Optionally link the request to an event or case.
6. Submit once and keep the record open while Rodyne confirms its state.
`/rank set`, `/promote`, and `/demote` create the same audited type of work from Discord.
## Approval rules
* The target rank controls the required approval count.
* The requester cannot approve their own request.
* Approvers must still have access when the queued work executes.
* Protected targets cannot be requested.
* A stale expected role stops the request rather than overwriting a newer change.
## State flow
```text theme={null}
Waiting for approval
↓
Queued
↓
Running
↓
Roblox updated → Discord sync pending
↓
Completed / Partially completed / Needs attention / Expired
```
Some workflows can move directly from running to a terminal state. Always read the target outcomes rather than inferring success from the last visible label.
## Batch requests
The member table can submit up to 100 selected rows with one reason. The API validates the entire batch together for tenant scope, current roles, protected targets, permissions, and duplicate retry keys. Approval counts remain per member and target rank.
## Partial and uncertain outcomes
If Roblox confirms but Discord synchronization fails, the record may be partially completed. Do not repeat the Roblox change manually. Repair the unconfirmed Discord step after checking live state.
If a network request times out after a provider may have applied it, Rodyne can mark the outcome uncertain. Read the provider state before any retry.
Use the outcome reference before retrying or repairing provider work.
## Guided walkthrough
The screenshot above is from the live Rodyne product. Use it to orient yourself, but rely on the current record state and live provider checks when operating the workspace.
## Operating procedure
Read the member's live mapped rank immediately before creating the request.
Verify mapping, protection, adjacency, and required approvals.
Describe the operational basis and attach the relevant event or case.
Use distinct currently authorized approvers; the requester cannot approve.
Confirm Roblox read-back and any required Discord role synchronization.
## Acceptance checks
| Check | Ready when | If it is not ready |
| ------------- | --------------------------------------- | -------------------------------------------- |
| Expected rank | Current rank still matches the request | Create fresh work after reviewing the change |
| Approvals | Required distinct approvers are present | Wait or route to eligible approvers |
| Targets | All required providers are confirmed | Repair only the unconfirmed target |
## Failure recovery
A partial result is not a reason to repeat the whole request. Preserve the confirmed Roblox result, diagnose the Discord target separately, and use the narrow repair action.
## Continue the workflow