Users, roles, and permissions¶

There is no single “admin panel” permission. Each administration page needs its own capability, such as managing users, changing settings, editing workflow rules, or importing risks, and you see only the menu items you have access to. This lets someone manage one area without automatically controlling everything.

Understand the access model¶

• A claim is one capability defined by RiskVault, such as submitting risks 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.

Make someone able to own risks¶

The Risk Owner Policy carries the treatment abilities a risk owner needs end to end: writing the treatment plan and sending it for approval, then starting, pausing, resuming, and completing the work. Assign it to anyone who will be named as a risk owner.

Approving a treatment plan is deliberately not included. The person who writes a plan shouldn't also sign it off, so approval stays with reviewers and executive approvers.

Being given the Risk Owner role and being named as the owner of one risk are different. Only the first grants abilities. If someone with, for example, a Contributor role is picked as a risk's owner, they get access to that risk but none of the treatment abilities. RiskVault stops that at the point of assignment (see Who can be a risk owner). The person assigning is offered a one-click fix if they can manage users; otherwise the request comes to you.

When someone uses the one-click fix, the audit history records who granted the policy and to whom, just as if it had been assigned from the user editor. The change takes effect immediately: the recipient's cached abilities are cleared, and user pickers that filter by ability find them on the next search.

Existing installations receive the added abilities automatically the next time the application starts. People already holding the policy may need to sign out and back in before the change reaches them.

Enable resource reassignment¶

Resource reassignment adds the Resources card to each risk and Assign resource to the register's bulk actions (see Change who is assigned to a risk). It is off until it's switched on for the installation.

Unlike most optional features, this is a deployment setting, not an in-app switch. It lives in the application's configuration (Features:RiskResourceReassignment) and takes effect when the application restarts. Whoever runs your deployment turns it on.

Before enabling it:

• Run the database migrations first. The feature stores its own assignment history and notification records.
• Tell the people who reassign work regularly. Assignments tighten slightly: Closed, Archived, and Rejected risks can no longer be reassigned in bulk, bulk assignment requires a preview first, and changing someone once work is under way requires a reason.

With the feature off, the owner, reviewer, and action owner are changed from the Details pencil or the Edit page, and Assign owner remains in the register's bulk actions.

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.