RBAC

Role-Based Access Control for workspace members, resources (permission keys), and roles. Use the Console to define resource keys before passing the same strings to SDK methods such as openAuthIdpModal.

What the RBAC Panel Does

The RBAC panel provides a modal dashboard with three tabs:

• Members Tab - Registered-member management with add, delete, role assignment, sorting, and pagination
• Resources Tab - Create and edit resource keys that power {resource}:{action} permissions and SDK resource strings
• Roles Tab - Role lifecycle plus the permission matrix (per resource × CRUD / step-up)

Prerequisites

• Active Transcodes project

Opening the RBAC Panel

The RBAC modal opens in the center with three tabs: Members, Resources, and Roles

Members Tab

The Members tab lists every workspace member (end-user account in your project) with full management capabilities.

The Members tab shows:

• Registered Members section header (may read “Registered Users” in the UI)
• + Add Member button (top-right) (may read + Add User)
• Member table with columns:
  • Email
  • Name
  • Registered (sortable with ↓)
  • Last Active (sortable with ↓)
  • Role (dropdown selector)
  • Member UID (monospace font, truncated) (may read “User UID”)
  • Actions (delete button)
• Pagination controls (Page 1+, < >)

View Members

The member table displays up to 50 members per page with pagination controls at the bottom

Table columns:

Sort Members

To sort the member table:

1. Click any column header with a sort indicator (↓)
2. Available sort fields:
   • Registered (createdAt) - Sort by registration date
   • Last Active (updatedAt) - Sort by last activity (default)
3. Click again to reverse the sort order (asc ↔ desc)
4. Table automatically resets to page 1 when sorting changes

Add Member

To add a new member:

1. Click the + Add Member button (top-right) (or + Add User if shown)
2. The Add New Member modal appears (titles may say “Add New User”)

3. Fill in the form fields:

4. Click CREATE MEMBER (may read CREATE USER)
5. The member appears in the table immediately

Example metadata:

{
  "department": "engineering",
  "plan": "premium",
  "team": "backend"
}

Role assignment:

• Select a role from the dropdown (only shows existing roles)
• Leave empty to create a member without role assignment
• Role can be assigned or changed later from the table

Update Member Role

To change a member’s role:

1. Find the member in the table
2. Locate the Role column for that row
3. Click the role dropdown
4. Select a new role from the list:
   • user (built‑in role name, not “Users” vs “Members” wording)
   • Any custom roles you’ve created
5. The role updates automatically

Delete Member

To delete a member:

1. Find the member in the table
2. Click the delete button in the Actions column
3. The delete confirmation modal appears (may read Delete User)

4. Review the confirmation message showing the member’s email
5. Click DELETE to confirm (or CANCEL to abort)
6. The member is permanently removed immediately

Resources Tab

The Resources tab is where every permission—and every SDK call that passes resource:—gets its canonical key from the Console. Strings such as 'documents' in openAuthIdpModal({ resource: 'documents', action: 'write' }) are not invented in code alone; they must exist here (unless you mirror them programmatically).

Why resources belong in the docs

Integration samples often demonstrate:

openAuthIdpModal({ resource: 'documents', action: 'write' });

That documents value is resolved the same way in every environment:

1. Console → RBAC → Resources — define the resource key once.
2. Console → RBAC → Roles — edit a role’s permission matrix so the desired role includes the correct resource + action tier (Allow / Deny / Allow + step-up—see § Assigning Permissions to Roles).
3. App / SDK — pass the identical resource and action strings.

If you omit step 1, you end up configuring roles against resource keys nobody has created yet—easiest unblock is visiting the Resources tab early (or using MCP automation below).

View Resources

Expect a compact table analogous to Roles:

Exact labels may ship ahead of screenshots; when in doubt, copy resource keys verbatim into your SDK integration.

Add Resource

To register a new resource key:

1. Open the RBAC modal and switch to Resources.
2. Click Add Resource (or +) to launch the creation form.
3. Fill in fields (names may vary slightly):

4. Submit (e.g., CREATE) and confirm it appears in the table.

Resources are deliberately flexible—you model whatever domains your SaaS exposes. Prefer short, hyphenated ASCII keys (user-profiles > User Profiles API v2 slug).

Edit Resource

1. Locate the row in the Resources tab.
2. Use Edit to adjust display name or description.
3. The resource key (key) stays immutable in most deployments so existing JWT claims, SDK calls, and audit entries continue to validate.

Need to rename an entity dramatically? Prefer creating a replacement key plus a migration checklist rather than repurposing legacy keys silently.

Delete or Retire Resources

Deleting a resource is destructive for your permission grid—expect Console warnings and possible step-up confirmations. Mirrors the MCP tool retire_resource (management token + verified session). Ensure no role still relies on obsolete keys before removal.

Programmatic Alternative: MCP create_resource

Administrative tooling for resources/roles rides the Transcodes MCP server—not modal SDK methods. Typical workflow:

MAT (management access token)
  → MCP client/agent
     → Transcodes MCP tool "create_resource" { key, name, description }

Immediately follow with set_role_permissions (often Verified Action requiring step-up MFA) so new keys are more than placeholders. Bulk migrations should follow upstream guidance in llms-full.txt: create_resource → create_role → matrix updates → membership creation ordering matters.

Console remains the quickest path when you spin up demos without agents.

Roles Tab

The Roles tab allows you to create, edit, and delete custom roles for your application

The Roles tab shows:

• Role Management section header
• + Add Role button (top-right)
• Role table with columns:
  • Name
  • Description
  • Created At
  • Updated At
  • Actions (Edit button, Delete button)

View Roles

The role table displays all custom roles created for your project

Table columns:

Add Role

To create a new role:

1. Click the + Add Role button (top-right)
2. The Add New Role modal appears

3. Fill in the form fields:

4. Click CREATE ROLE
5. The role appears in the table immediately

Role naming guidelines:

• Use lowercase letters, numbers, and underscores
• Examples: admin, moderator, editor, viewer, guest
• Role name must be unique within your project
• Role name cannot be changed after creation

Example role descriptions:

Full access to all features and settings

Can moderate content and manage members

Read-only access to content

Edit Role

To edit a role’s description:

1. Find the role in the table

2. Click the Edit button in the Actions column

3. The Edit Role modal appears

4. Update the Description field (Role Name is disabled and cannot be changed)

5. Click UPDATE ROLE

6. Changes are saved immediately

Delete Role

To delete a role:

1. Find the role in the table

2. Click the delete button in the Actions column

3. The Delete Role confirmation modal appears

4. Review the confirmation message

5. Click DELETE to confirm (or CANCEL to abort)

6. The role is removed immediately

Before deletion:

• Check the Members tab to see which rows still use that role
• Clear those assignments via the Members tab role dropdown
• Once no member has that role assigned, delete the role

3-Tier Permission Model

Beyond basic role assignment, Transcodes RBAC supports a 3-tier permission model that provides fine-grained access control:

Roles → Permissions → Resources

Creating Permissions

Permissions are defined as {resource}:{action} pairs:

Common actions:

• read - View resource data
• write - Create or update resources
• delete - Remove resources
• manage - Full control including settings

Example permissions:

documents:read
documents:write
documents:delete
users:read
users:manage
settings:manage

Assigning Permissions to Roles

1. Navigate to the Roles tab in the RBAC panel
2. Click Edit on the role you want to configure
3. In the permission matrix, set Allow / Deny / Allow requiring step‑up MFA per resource × action. Only resources you created in Resources Tab—plus built-ins such as system—appear here meaningfully for new grants
4. Click UPDATE ROLE to save (may require verified step‑up MFA when changing sensitive matrices)

Each role can have multiple permissions. Members inherit permissions from their assigned role.

Resource Definitions (conceptual examples)

Concrete keys belong in Resources Tab. The pairs below illustrate how domain concepts map once those keys exist—you must register each key unless your project already seeded it:

SDK calls pass the literal key string—for example 'documents' and 'write' once that role allows the pairing in the Console matrix.

SDK Integration

resource and action must match keys and matrix rows from Resources Tab plus Roles. Use the Transcodes SDK modal parameters:

// Open the auth modal with resource/action context
openAuthIdpModal({
  resource: 'documents',
  action: 'write',
});

The SDK validates the authenticated member’s role matrix against the requested resource and action. If that grant is missing, the modal applies the denial path automatically.

For step-up authentication on sensitive resources, combine with Step-up Session:

// Require re-authentication for admin actions
openAuthIdpModal({
  resource: 'settings',
  action: 'manage',
  stepUp: true,
});

What to do next?

After managing members, resources, and roles:

1. Track workspace activity with analytics charts
2. Download backups for data retention (member-related exports)
3. Configure authentication settings for your workspace members
4. Review Member API for programmatic member management