User roles
A role determines what its members can see and change in the portal. Assign each role a level for every area of the portal, then add users to one or more roles. Roles are managed in Admin center → Roles.
- How roles work
- Permission levels
- Roles and your plan
- Access right areas
- Creating a role
- Designing roles with the AI assistant
- Default role for SSO users
- Role titles and case tasks
- Deleting a role
How roles work
Every new account starts with one role called Admin, which has Full Control for every area, and the person who signed up is its member. Keep at least one person in a role with these permissions, because only a role with User Accounts set to Update or higher can open the Roles and Users pages.
A user can belong to several roles. For each area, the user receives the highest level granted by any of their roles, so a user with Read on Decision flow in one role and Update on Decision flow in another can edit decision flows.
Changes to a role apply to all its members as soon as you save.
Permission levels
Each area has one of four levels. The levels build on one another, so changing requires viewing first, and running requires changing first.
| Level | What the member can do |
|---|---|
| None | The area remains visible in the menu, but nothing in it can be read or changed. When a member tries to open or change something, the server refuses and the portal shows “You do not have enough rights to perform this action.” |
| Read | Open and inspect items, without changing them. |
| Update | Everything in Read, plus create, edit and delete. |
| Full Control | Everything in Update, plus run, test or deploy where the area has such an action. |
A role must grant at least one area above None before it can be saved.
Roles and your plan
The rights a member has in an area are the levels their roles grant, limited by the areas your account’s plan includes.
- An area that is not in your plan can still be read. In that area, Update and Full Control act as Read.
- When the plan does not include a page or an action, the portal shows “Not in your plan.” with a Choose a plan link.
- In the Admin center, cards for areas that are not in your plan are hidden.
- User Accounts, Subscription, Credential Vault and Manage sink connections are never limited by the plan.
- After a plan downgrade, items you already have remain visible, but they cannot be changed or run.
The levels on a role page are the role’s own. The plan does not change them.
Access right areas
The platform supplies the list of areas on a role page, and the list grows as features are added. On the role page, areas appear by title in alphabetical order.
| Area | What it covers | What Full Control adds |
|---|---|---|
| API endpoint | The endpoints callers use to reach a decision flow, and their API keys | Sending a test call through an endpoint |
| Approval process | The review and sign-off chains that changes go through before release | Acting on an approval step |
| Batch | Bulk runs that score many records against a release in one job | Starting a bulk run |
| Case design | Case designs: record types, tasks and the decisions in a case | Running a case design against test data |
| Credential Vault | The credentials that data sources and services sign in with. Read shows names and kinds only, never values | Nothing beyond Update |
| Dashboard | Reports and analytics over past decisions | Nothing beyond Update |
| Data object | The attribute catalogue that every decision flow reads and writes | Nothing beyond Update |
| Decision flow | Decision flows: their steps, branches and order | Running test executions of a flow |
| Decision table | Decision tables | Running a table against test data |
| Decision tree | Decision trees | Running a tree against test data |
| Deployment | Putting a release on a runtime so it answers real traffic | Performing the deployment |
| External data | Connections to outside services called during a decision, and how their responses are mapped | Making a live call to the outside service |
| Functions | Calculation functions and formulas used in decision flows | Running a function against test data |
| Manage list entries | Entries of block, allow and watch lists: viewing, adding, removing and uploading them | Nothing beyond Update |
| Manage sink connections | Connections that deliver decision logs into your own database or storage | Testing a connection |
| Model | Models, both prompt-based and uploaded, with their inputs and outputs | Running a model against test data |
| OCR service | Settings for the service that reads data from uploaded documents | Testing the service |
| Operate | The Operate application, where business users work on live cases. Read lets members see cases and tasks, with a “Read only” label and case-changing controls disabled. Update lets them fill in and submit tasks, open cases and pass tasks on. Update also adds the All inbox view alongside Mine and My queue. With Read only, the inbox offers Mine and My queue. | Nothing beyond Update |
| Policy Document | The shared library of uploaded policy documents | Nothing beyond Update |
| Release | Releases: versioned snapshots of the decision logic, and comparisons between them | Nothing beyond Update |
| Rule set | Rule sets and their rules | Running a rule set against test data |
| Scorecard | Scorecards: scored attributes, bands and weights | Running a scorecard against test data |
| Subscription | Your plan, billing details and invoices | Nothing beyond Update |
| User Accounts | Users, roles and their permissions. At Read, members can open the Audit trail but cannot change users or roles. | Nothing beyond Update |
The audit trail, in Admin center → Audit trail, records every action a member takes through the portal, including actions the server refuses because their roles do not allow them. Each entry includes the member’s name, the time and the IP address.
Areas to grant with care
- User Accounts at Update makes a role an administrator role. Its members can edit any role, including their own, which allows them to give themselves every other area.
- Deployment at Full Control changes what production answers. Release and Deployment are separate on purpose, allowing one person to prepare a release while another puts it live.
- Credential Vault at Update lets members add or replace the credentials your data sources sign in with.
- External data at Full Control makes real calls to outside services, which the provider may bill.
- Data object at Update changes attributes shared by every decision flow, rather than only the flow a person is working on.
- Operate is for people who work on cases, and they usually need few or none of the design areas.
Creating a role
- Go to Admin center → Roles and click Add role.
- Enter a Title that is 2 to 100 characters long and differs from every other role title when upper- and lower-case differences are ignored.
- Set a Permission for each Access right area, starting with the person's job and assigning the lowest level that allows them to do it.
- Click save, or press Ctrl+S.
The new role opens after saving. To change it later, click its title in the list; to add users as members, see Users.
Designing roles with the AI assistant
The sparkle button (AI Assistant) opens a chat where you describe the job in plain language, and the assistant proposes permission levels. It explains its choices and identifies any area from Areas to grant with care that it sets.
The assistant works in two places, and Apply changes has a different effect in each one:
| Opened from | What you can ask | What Apply does |
|---|---|---|
| A role page, or Add role | Set the permissions for this one role, for example "a risk analyst who reviews and tests the logic but must not deploy" | Fills in the title and levels on the page. Nothing is stored until you save. |
| The Roles list | Design several roles at once, or review the roles you already have, for example "internal audit, plus a rule analyst and a risk manager who can approve" | Creates the new roles and updates the changed ones straight away. Each proposed role is marked New or Modified before you apply. |
Review the proposed table before applying it. Areas omitted from the proposal keep their current level.
Default role for SSO users
If your account signs users in through SSO, each role page shows the option Is default SSO role?. When someone signs in through SSO for the first time, Decisimo creates their user account and adds them to every role marked as default.
The option applies only when the account is created, so changing it later does not add or remove existing users. Use Users to make those changes.
Role titles and case tasks
Case designs send human tasks to roles by title. A task with an assignee role appears for every user who belongs to a role with that title, without regard to upper- and lower-case differences.
Renaming a role changes who receives those tasks. Tasks that contain the old title remain without a matching role until the case design is updated. Do not use commas in a role title, because a task offered to several roles stores their titles as a comma-separated list.
Deleting a role
Open the ⋮ menu next to the role in the list, or the settings menu on the role page, and choose Delete.
Members immediately lose the rights that role provided. A user who belonged only to that role keeps their account but has no rights until you add them to another role. The last remaining role in an account cannot be deleted.