Roles and PermissionsCopy Anchor Link

Strise uses role-based access control. Every user in a team holds one or more roles, and each role grants a fixed set of permissions. What you can see and do in Strise is determined by the roles you hold — actions you don't have permission for are simply not shown.

This replaces the previous two-level setup ("User" and "Manager") with four clearly scoped roles, so your team can give every person the right level of access — no more, no less.

The rolesCopy Anchor Link

New members are given the Analyst role by default when invited.

AnalystCopy Anchor Link

The standard role for anyone working cases in Strise. Analysts can:

• Run reviews end-to-end and complete assessments
• Handle PEP, sanctions, and adverse media dispositions
• Edit entity data: roles, owners, contacts, tags, assignees, risk fields
• Add companies and persons to the portfolio and manage entity statuses
• Order identity verification, credit reports, and registry documents
• Manage documents, comments, reminders, and data-collection forms

Analysts cannot change team-wide settings, manage members, or perform the bulk and sign-off actions reserved for Managers.

ManagerCopy Anchor Link

The role for compliance leads. Managers hold every Analyst permission, plus:

• Rules settings -- review triggers, risk classes and flags, PEP, sanctions, and adverse media configuration, monitoring settings, and review PDF setup
• Bulk operations -- bulk alert handling
• Sign-off -- four-eyes assessment approval
• Clean-up rights -- deleting uploaded documents, comments, and private persons

Managers do not manage members — that sits with the Team Admin.

Team AdminCopy Anchor Link

The role for whoever owns the team's setup. Team Admins can:

• Invite, edit, and remove members
• Assign and change roles for any member of their team
• Follow the team's activity log
• Connect, change, and disconnect integrations
• Manage CRM field mapping
• Run data migrations

Team Admins can see casework — reviews, alerts, assessments, entity data — but cannot change any of it, and hold no rules settings by design. Those sit with Managers. Separating who administers the team from who decides and configures compliance work is a segregation-of-duties principle many regulated organisations require. A person who genuinely does both simply holds both roles — see Combining roles.

Read-onlyCopy Anchor Link

A strictly read-only role. Users with this role can view the portfolio, monitoring, reviews, and entity data, but hold no write permissions of any kind. Suited for internal audit, external examiners, or anyone who needs full visibility without the ability to change anything.

Combining rolesCopy Anchor Link

Roles are additive. A user can hold any number of roles, and their permissions are the union of everything those roles grant. Common combinations:

Custom rolesCopy Anchor Link

When the four built-in roles don't fit, an organisation administrator can build its own. A custom role is a name, a description and a set of permissions picked from the same catalogue the built-in roles draw on — grouped by what they act on, each with a description of what it allows. A new role can start blank or from a copy of an existing one, and can be offered to everyone in the organisation or only to one team.

One thing to know before relying on them: a custom role is a snapshot. It does not pick up new permissions when Strise ships a feature, so a team using custom roles should review them when a feature they care about launches. Built-in roles are maintained by Strise and stay current on their own.

Custom roles are built under Organisation → Roles & permissions, documented in Roles & Permissions. The same page shows exactly what every built-in role grants.

Managing rolesCopy Anchor Link

Roles are managed in two places, depending on how far your remit reaches.

Managing one teamCopy Anchor Link

Team Admins manage the team they are working in under Settings → Members. The members view shows every member of the team with their roles, and lets Team Admins invite new members, change roles, and remove members without contacting Strise. Roles granted at the organisation level are shown read-only here — they can only be changed where they were granted. See Members.

Not sure which roles you hold? Open Settings → Members and find yourself in the list.

Managing every teamCopy Anchor Link

Organisation administrators get a separate destination that spans every team: open the account menu (your avatar, top of the sidebar) → Organisation. It is where users, teams and roles are managed across the whole organisation rather than one team at a time.

Each page appears only if your roles carry the permission behind it, and every action is enforced again on the server. A team-level administrator cannot reach the area at all. See Organisation.

Activity logCopy Anchor Link

Every change to who can do what in your team is recorded. Team Admins find the log under Settings → History → Activity. It shows who assigned, changed, or removed a role, and who invited or removed a member — with the actor, the target, and the time. Changes made through the API are recorded the same way as changes made in the app. Organisation admins also get one log across all teams under Organisation → Activity. See Activity Log.

What happened to "User" and "Manager"?Copy Anchor Link

The previous roles were mapped automatically when the new roles launched:

No data, settings, or workflows were changed by the migration. If someone on your team needs one of the moved actions, a Team Admin can grant them the Manager role.

How permissions are enforcedCopy Anchor Link

Permissions are enforced in the Strise backend on every action — not just in the interface. Buttons and options you lack permission for are hidden, and the same checks apply to direct links and API calls. The four built-in roles are maintained by Strise, so each one means the same thing in every team and every organisation; a custom role means whatever your own administrators gave it.

What's coming nextCopy Anchor Link

These four roles are the first step of a three-step plan.

Step 2 — governance and identity. Shipped so far:

• Custom roles (September 2026) -- build and maintain your own roles when the standard four don't fit. See Custom roles.
• Organisation-level administration (September 2026) -- manage users, teams and roles across all your teams from one place. See Managing every team.
• Single sign-on with SCIM -- connect your identity provider so users are provisioned and deprovisioned automatically, with your identity-provider groups mapped to Strise teams and roles. Joiners, movers, and leavers stay in sync without anyone touching Strise. Talk to your customer success manager about setting it up.

Still to come in this step:

• Role expiry.

Step 3 — access control for the AI era. As AI agents start taking part in compliance work, they need the same rigour as people: their own roles, permissions, and audit trails. This step isn't scoped yet, but the work starts in the coming months.

We keep the exact order and timing flexible on purpose, so feedback on these roles can shape what ships first. Talk to your customer success manager about what matters most to you.

Questions?Copy Anchor Link

Reach out to your customer success manager or support@strise.ai.