Roles and Permissions

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 roles

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

Analyst

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.

Manager

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

• Policy 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 Admin

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
• 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 policy 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-only

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 roles

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

Managing roles

Team Admins manage roles directly in the app 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.

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

Activity log

Every change to who can do what in your team is recorded. Team Admins find the log under Settings → 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.

What happened to "User" and "Manager"?

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 enforced

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. Each role's permissions are fixed and maintained by Strise, so the same role means the same thing in every team.

What's coming next

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

Step 2 — governance and identity. In design now. The planned scope:

• Single sign-on with SCIM -- connect your identity provider so users are provisioned and deprovisioned automatically, with your identity-provider groups mapped to Strise roles. Joiners, movers, and leavers stay in sync without anyone touching Strise.
• Custom roles -- build and maintain your own roles when the standard four don't fit.
• Customer-level administration -- manage members and roles across all your teams from one place.
• Organisation-wide activity log -- one log across all your teams, not one per team.
• 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?

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