Skip to main content
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

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.

Understand every job state

Use the outcome reference before retrying or repairing provider work.

​
Guided walkthrough

Rodyne rank request queue with approval and execution status

Rank requests expose policy, approvals, and provider execution as one reviewable chain.

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

1

Confirm current state

Read the member’s live mapped rank immediately before creating the request.
2

Choose the exact target

Verify mapping, protection, adjacency, and required approvals.
3

Write a durable reason

Describe the operational basis and attach the relevant event or case.
4

Collect independent approval

Use distinct currently authorized approvers; the requester cannot approve.
5

Verify both providers

Confirm Roblox read-back and any required Discord role synchronization.

​
Acceptance checks

​
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

Configure roles and ranks

Read job outcomes