Users, roles, and permissions

Guardhouse supports reusable role-based access control and direct user permissions. Keep these application permissions separate from System Access, which controls administration of Guardhouse itself.

Understand the access model

• A permission is a named application capability with a stable key and description.
• A role groups permissions for a job or responsibility.
• A direct permission grants an exception to one user without creating a role.
• System Access grants Guardhouse administrative capability and is reviewed separately.
• A resource scope controls what a client may request from an API; it is not the same as a user's role or permission.

Guardhouse combines permissions received through roles with direct permissions. There is no direct-permission deny that cancels a grant from a role.

Manage the user lifecycle

Open Users to create a user or inspect an existing account. Depending on the user's state and your own access, available actions include:

• create and update the user's name and email;
• invite or reinvite the user to the admin dashboard or an application;
• create or change a password;
• block or unblock access;
• reset configured MFA;
• review the user's activity;
• remove personal data;
• delete the user.

User records can move through Staged, Invited, Active, and Archived states. Treat status as lifecycle information; use the explicit Block action when access must be suspended immediately.

When inviting a user to an application, select the intended client and redirect destination. Do not send an administrator invitation when the user only needs application access.

Destructive actions

Removing personal data and deleting a user are different destructive operations. Read the dashboard confirmation carefully, confirm retention and legal requirements, and export required audit information before continuing.

Define permissions

Open Access Control → Permissions:

1. Create a stable machine-readable key.
2. Add a clear display name and description.
3. Use one permission for one meaningful capability.
4. Review which roles use the permission before changing or deleting it.

Avoid keys tied to a person's name or a temporary project structure. Applications should use stable keys for authorization and treat display names as administrator-facing text.

Define roles

Open Access Control → Roles:

1. Create a stable role key, name, and description.
2. Select the permissions needed for that responsibility.
3. Save the role and review its effective permission list.
4. Assign the role to users who share that responsibility.

Prefer a few focused roles over a single all-powerful role. Update a role when the responsibility changes instead of editing every user individually.

Assign user access

On the user's Roles and permissions tab:

• assign roles for normal access;
• use direct permissions only for documented exceptions;
• review overlapping role grants before adding a direct permission;
• remove obsolete direct grants when a role replaces them.

Test authorization with a non-administrator account. A successful login proves identity, not permission to perform every application action.

Grant System Access carefully

The user's System Access tab controls Guardhouse administration. Grant it only to named administrators who need to manage the tenant.

• Do not use System Access as an application role.
• Do not give a machine administrative access unless it uses a dedicated service client and the supported System API workflow.
• Require strong authentication for administrators.
• Review System Access independently during access reviews.

Configure the user profile

Organization profile settings determine whether users may change their own:

• name;
• avatar;
• email address;
• account-deletion state;
• personal-data export.

Enable only the self-service actions your support, verification, and data-retention processes can safely handle.

Access-review checklist

• Review administrators and high-privilege roles on a schedule.
• Block accounts promptly when access must stop.
• Remove direct permissions that no longer have an owner or justification.
• Check user activity after MFA resets, email changes, and recovery events.
• Keep production roles separate from test tenants and sample data.
• Verify application enforcement after changing permission keys or role membership.