Users, roles, and permissions

Administration access begins with Admin.AccessPanel. Individual pages require additional capabilities, so an administrator can manage one area without automatically controlling everything.

Understand the access model

  • A claim is one capability defined by RiskVault, such as creating a draft or managing users.
  • A policy bundles claims into a reusable set.
  • A role represents a job function and links to one or more policies.
  • A per-risk permission grants selected access to one record.

Assign reusable job access through roles and policies. Use a per-risk permission when someone needs one exceptional record. Avoid one-off broad claims unless there is a documented reason.

Add or invite a user

  1. Open Administration > Users.
  2. Choose the invitation or create-user action appropriate to your sign-in model.
  3. Enter the person's verified name and email address.
  4. Set the business unit where applicable.
  5. Assign the smallest suitable role or policy.
  6. Send the invitation or save the account.
  7. Ask the user to sign in and review My Account > My Claims.

Image needed: User administration list and invite form with email, business unit, roles, and policies labeled.

Administrators can resend or cancel invitations, lock and unlock accounts, send password-reset instructions, and soft-delete eligible users.

Create a policy

  1. Open Administration > Policies.
  2. Review existing policies before creating another.
  3. Give the policy a name that describes its business purpose.
  4. Select the required claims from the Claims Reference.
  5. Save the policy.
  6. Link it to an appropriate role or assign it directly when justified.
  7. Test it with a normal, non-admin account.

Use Claims Reference, Roles, Policies, and the Permissions Catalogue together when tracing effective access.

Change or remove access

  1. Open the user, role, or policy.
  2. Record why the change is needed according to your internal process.
  3. Remove or replace access.
  4. Save, then verify the user's effective claims.
  5. Confirm important server-side actions, not only menu visibility.

RiskVault blocks deletion of roles and policies that are still in use. Remove their assignments and relationships first. The built-in Admin role and policy cannot be deleted or renamed.

Avoid lockout

Keep at least one tested administrator access path before changing external sign-in, SCIM, or high-level policies. Test critical changes with a second administrator session and a normal-user session.

Account lifecycle

Lock and unlock

Lock an account when access must stop temporarily without removing the record. Unlock only after confirming identity and authorization. A lock can affect active work assignments, so review urgent tasks and reassign them when necessary.

Password reset

For a local account, send the built-in password-reset instruction rather than setting or sharing a password manually. People using external sign-in normally reset credentials with the identity provider.

Delete or deactivate

Removing a user is a controlled offboarding action. RiskVault preserves relevant history and references. Before proceeding:

  1. Review owned risks, review assignments, approvals, reports, schedules, and integration ownership.
  2. Reassign work that must continue.
  3. Confirm whether SCIM or an administrator controls the account lifecycle.
  4. Deactivate or delete according to policy.
  5. Verify the user cannot sign in.

SCIM will not automatically reactivate a person whom an administrator removed for cause unless the application's explicit rules allow it.

Assign direct policies carefully

A direct policy can be useful for an exception that does not match a job role, but it is easier to overlook later.

  1. Record the reason and expected review date.
  2. Choose an existing narrow policy where possible.
  3. Assign it directly to the user.
  4. Verify effective claims.
  5. Review and remove the exception when it expires.

Diagnose effective access

When a user reports a missing feature:

  1. Confirm the correct account and business unit.
  2. Review direct policies and assigned roles.
  3. Expand each role to its policies and claims.
  4. Check the feature switch.
  5. Check per-risk permissions and confidentiality.
  6. Check workflow state and assignment.
  7. Test the exact server-side action with an equivalent non-admin account.

Image needed: Effective-access troubleshooting view showing a fictional user, assigned roles, inherited policies, and effective claims.

Periodic access review

At an interval appropriate to your organization:

  • review administrator and integration-management capabilities;
  • remove unused direct policies;
  • confirm roles still match job responsibilities;
  • check locked and inactive accounts;
  • review exceptional per-risk permissions on sensitive records;
  • verify at least one tested emergency administrator access path.