Skip to main content

Manage app roles

App Role management is Console-only. A new role synchronizes a Role Policy that initially grants wildcard resource and action access. Review and narrow that policy before assigning the role to a user, then verify an allowed and denied access decision.

Prerequisites​

  • Select the target app and define the least-privilege resources and actions the synchronized Role Policy should allow.
  • Identify the users who should receive the role and whether a Site Role should bundle it.
  • Choose a narrow role purpose that does not duplicate a resource condition.

Create the role​

  1. Open the target app, select Roles, then select Create Role.
  2. Enter Name and Description. The name and generated slug cannot be changed after creation.
  3. Enable Default Role only when every new site user should receive this App Role automatically.
  4. Select Parent Role when the role should sit below a particular role. A non-Super-Admin role created without an explicit parent defaults beneath the app's Super Admin role. The parent must belong to the same app.
  5. Select Create Role and confirm the new role appears in Roles.

Creation fails for a duplicate name, a missing Super Admin root, or an invalid parent. Moving a role below itself or one of its descendants is rejected as a circular hierarchy.

Verify synchronization and narrow access​

  1. Open the Policy Editor and confirm the synchronized Role Policy exists. Role creation can succeed even when policy synchronization fails. If the Role Policy is missing, stop and contact TaruviBase support with the site, app, and role name.
  2. Review its initial resource wildcard and action wildcard. This broad default can grant the assigned role access across resources and actions.
  3. Use Manage policies in the Console to narrow the Role Policy to the approved resources and actions before assigning users.
  4. Save the complete definition and confirm the Role Policy appears in the app's policy list.

Assign the role and test decisions​

Assigning a parent role also grants its descendant App Roles as inherited roles. Review the complete subtree before assigning a broad parent.

  1. Open the role and select Manage Users, or use Assign user access when the assignment is part of a wider site-user workflow.
  2. Verify the assigned user shows the intended direct or inherited membership.
  3. Inspect Matrix and Flow, then use Live Testing to verify a caller with the role is allowed and a caller without it is denied.

A separate resource policy is not required for a Role Policy grant. Use a resource policy only when the resource needs its own role or condition rules.

A Site Role can bundle this App Role with roles from other apps. Manage that bundle from the Auth guide linked above; it is distinct from the App Role's parent hierarchy.

Edit the role​

  1. Open the role and select Edit Role.
  2. Change Description, Default Role, or Parent Role, then select Save Changes. The role name cannot be changed.
  3. If the parent changes, review every user who may gain or lose inherited descendants, then rerun the allowed and denied decision tests.

Delete the role​

Confirm App Role deletion
  • Affected resource and cascade: Identify the App Role, its direct and inherited users, descendant roles, Site Role bundles, synchronized Role Policy, and every resource policy that names it. The deleted role's memberships and Site Role links are removed. Move children to parent keeps child roles and their policies but reparents direct children. Delete all child roles permanently deletes every descendant, its memberships and Site Role links, and its synchronized role policy.
  • Reversibility: Delete Role cannot be undone. A role name change also requires delete and recreate.
  • Authorization: Confirm you are allowed to change roles and access for the selected app.
  • Backup or export: Note the role tree, descriptions, default flags, direct members, Site Role bundles, the Role Policy definition, and any resource policies that reference the role.
  • Confirmation: Confirm the exact App Role and choose either Move children to parent or Delete all child roles after reviewing the affected descendants.
  • Success response and postcondition: Confirm the role disappears from Roles, memberships and Site Role links are removed, the chosen child behavior occurred, synchronized policy state is correct, and affected users receive the expected allowed and denied decisions.
  • Recovery: Recreate roles parent-first, verify and narrow each synchronized Role Policy, restore Site Role bundles and direct memberships, restore any resource-policy references, and rerun allowed and denied tests.

Open the role, select Delete Role, choose the child-role behavior, and select Delete Role again only after completing the controls above.

Verification​

You're done when the role hierarchy, assignments, Role Policy, any resource policies, and allowed and denied test decisions all match what you intended.

Do not use app roles to bypass a condition that must be evaluated against the caller or resource. Keep the role narrow enough that its later use is clear in the policy matrix and Flow views.