Users and roles

User administration is under Users and Roles in the administration section.

Creating a user

Self-registration is disabled by default, so accounts are created by an administrator from the Users screen. You supply the account details; the new user completes their own password setup rather than being handed one.

Do not enable self-registration on an internet-facing deployment

Setting AccountSecurity:AllowSelfRegistration to true re-opens anonymous account creation and marks the new account email-confirmed without sending any mail. There is no confirmation round trip. Anyone who can reach the sign-in page can create a working account.

The Users screen. Accounts are created here; roles are assigned per account.

System roles

Five roles are seeded with the schema and cannot be removed:

Role	Grants access to
Administrator	Every administrative screen, including users, roles, and configuration.
RecordsManager	Records lifecycle: retention, governance, repository-wide document management.
WorkflowManager	Authoring and managing workflow definitions.
Auditor	Audit and reporting surfaces, read-only.
User	Ordinary workspace use.

Authorisation policies are built on these, plus a MetadataConfiguration policy that gates the content type, taxonomy, and numbering screens.

Custom roles can be created alongside the system ones, renamed, and deleted. Membership is managed from each role’s members screen.

A role is not access to content

Roles gate administrative screens. They do not, by themselves, grant access to any folder or document. Repository access always comes from an access-control entry.

Roles can be used as ACL subjects, which is a different thing: granting the Auditor role Reader on a folder is an access-control entry that happens to name a role. See Permission model.

Roles and their membership. Custom roles sit alongside the five seeded system roles.

Choosing roles

Give Administrator to as few people as the organisation can tolerate. The three specialised roles exist so that the common reasons for needing elevated access - managing records, authoring workflows, reviewing audit trails - do not each require full administrative control.

Auditor is the one most often overlooked. Someone who needs to review the audit log does not need the ability to modify the repository.

User profiles

Profiles hold the descriptive information attached to an account: display details, department, and organisation unit membership. Department and organisation unit membership is what makes group-based access grants work, so it is worth keeping accurate - see Departments and org units.

A backfill action exists to provision profiles for accounts that predate the profile feature or were created outside the normal flow. Run it once after an import rather than editing each account.

Account security

Setting	Default	Effect
AccountSecurity:MaxFailedAccessAttempts	5	Failed sign-ins before lockout.
AccountSecurity:LockoutMinutes	15	Lockout duration.
AccountSecurity:AllowSelfRegistration	false	Anonymous account creation.

Passwords require at least eight characters with upper case, lower case, and a digit. Email addresses are unique across accounts.

Two-factor authentication is available to every user through their own profile, using an authenticator app with recovery codes. It is not enforced centrally, so for administrator accounts it is worth confirming rather than assuming - the security health report lists accounts without it. See Reports.

When someone leaves

Deactivating an account stops the person signing in, but leaves work attached to them. Two things need attention:

1. Workflow tasks. A reconciliation job reassigns tasks belonging to a departed user, so they do not sit in an inbox nobody opens. Confirm the job is enabled - see Background jobs.
2. Access-control entries naming them individually. Group-based grants resolve themselves when membership changes; entries naming the individual do not. This is the strongest practical argument for granting to departments and roles rather than to people.

Related

• Permission model - what actually decides access.
• Departments and org units - grouping people.
• Security hardening - authentication configuration in full.