Roles: who sees what, who configures what
Every person in FlowLakes holds one platform base role and any number of application roles. The base role (Administrator, Configurator, Business User or Guest) decides how much of the tenant a person can configure. An application role (Service Desk Agent, Request Manager, Incident Admin and so on) decides what the person can do inside that application and which of its sections they see. An application’s own admin role configures the application’s own data. The stages of a Setup page that change tenant-wide settings, such as teams, SLA targets and notification rules, belong to a tenant administrator or to a Configurator who holds those capability areas.
When you’d use it
- A new service desk person needs access. Pick the application role that matches their job, and give it through a team.
- Someone must run the Incident desk end to end without being a tenant administrator: an application admin role plus the Configurator base role with the Service desk preset.
- A person sees a Setup page but cannot change a stage, and the page says a tenant administrator or a Configurator can.
- You are deciding who approves and want to know which role the approval stage asks for.
What you manage
The ladder
| Level | What it is | Where to set it |
|---|---|---|
| End user, Requester | Raises records through the portal and sees their own. The portal itself is open to every signed-in person. | An application role, through a team |
| Agent, Fulfiller, Implementer | Works the application’s records and tasks. Sees the application, not its Configuration section. | An application role, through a team. The Setup page’s Team stage gives it in one step |
| Manager, CAB Member | Works records plus approves, or reassigns. Sees the Configuration section and reads the Setup page. | An application role. The Approval stage gives the approver role |
| Application Admin | Full control of the application’s own tables and automations. Edits the Setup stages that change the application’s own data. | An application role |
| Configurator | A platform base role with a list of areas. Each area opens its admin pages and the tables that area owns, across the whole tenant. | Admin, Access & Governance, People, the person, Level |
| Administrator | A platform base role that passes every check and sees every installed application. | The same place. Give it sparingly |
Application roles are assigned to groups, and people join groups. A role belongs to one installed application: a tenant role that happens to share the name is not the application’s role. An application update can change what a role grants; read the update’s changelog in the Marketplace before applying it.
Roles that ship with each application
Incident Management. The Configuration section needs Incident Admin or Service Desk Manager.
| Role | Code | What it grants |
|---|---|---|
| End User | itsm_end_user | Create incidents through the portal and see their own |
| Service Desk Agent | itsm_agent | Work incidents and incident tasks; read categories and the priority matrix |
| Service Desk Manager | itsm_service_desk_manager | Service Desk Agent plus reassigning incidents and reading the Setup page |
| Incident Admin | itsm_admin | Full control of incidents, tasks, categories and the priority matrix; catalog items, workflows, business rules and approval policies |
| Incident AI Reader | itsm_ai_reader | Read-only data for the application’s agents. Not for people |
Request Management. The Configuration section needs Request Admin or Request Manager.
| Role | Code | What it grants |
|---|---|---|
| Request End User | request_end_user | Create requests through the portal and see their own |
| Request Fulfiller | request_fulfiller | Work requests and request tasks; read categories |
| Request Manager | request_manager | Request Fulfiller plus approving requests. This is the application’s approver role |
| Request Admin | request_admin | Full control of requests, tasks and categories; catalog items, workflows, business rules and approval policies |
Change Management. The Configuration section needs Change Admin or Change Manager.
| Role | Code | What it grants |
|---|---|---|
| Change Requester | change_requester | Raise change requests and track their own |
| Change Implementer | change_implementer | Work assigned change tasks |
| CAB Member | change_approver | Review and approve changes |
| Change Manager | change_manager | Own the change lifecycle, assess risk, approve normal changes, manage the schedule |
| Change Admin | change_admin | Change Manager plus emergency approval, CMDB writes and SLA policy configuration |
Asset Management (one module, Asset operations).
| Role | Code | What it grants |
|---|---|---|
| Asset Viewer | asset_viewer | Read software assets and asset lifecycle work |
| Asset Contributor | asset_contributor | Read software assets and coordinate asset lifecycle work |
| Asset Manager | asset_manager | Asset Contributor plus writing and reconciling software asset data |
Agile (one module, Delivery).
| Role | Code | What it grants |
|---|---|---|
| Agile Viewer | agile_viewer | Read projects shared with them |
| Agile Contributor | agile_contributor | Work items in projects they are added to |
| Agile Manager | agile_manager | Full rights inside projects they own or are added to |
| Agile Admin | agile_admin | Every project in the workspace, including members-only projects, so a project can be recovered when its owner leaves |
Who can change which Setup stage
A Setup page shows its stages to anyone who sees the application’s Configuration section. Changing a stage needs the permission its settings require. The table reads yes where the role alone is enough.
| Stage | Needs | Incident Admin | Request Admin | Configurator with the Service desk preset | Administrator |
|---|---|---|---|---|---|
| Intake, catalog items | Service catalog write | yes | yes | yes | yes |
| Intake, categories and priority matrix | Update on the application’s own tables | yes | yes | no | yes |
| Approval, the rules | Approvals write | no stage | yes | yes | yes |
| Approval, who approves | Identity and access write | no stage | no | yes | yes |
| Team | Identity and access write | no | no | yes | yes |
| Targets | Service definitions write | no | no | yes | yes |
| Updates | Notifications write | no | no | yes | yes |
| Automations | Business rules write | yes | yes | yes | yes |
| Assistant, on or off and who signs off | Tables write | no | no | yes | yes |
| Assistant, which connections | External configuration write | no | no | no | yes |
Change Admin holds Service definitions write and Approvals write, so it changes Targets and approval rules on its own. A stage a person cannot change shows its state and the line “A tenant administrator can change this, or a Configurator whose capabilities include Identity and access” (or the area the stage needs).
Let one person run a service desk
Give the person two things:
- The application’s admin role, for example Incident Admin, through their team. This covers the application’s own tables: categories, the priority matrix, catalog items and automations.
- The Configurator level with the Service desk areas. Open Admin, Access & Governance, People, select the person, and under Level choose Configurator. The first time, the Service desk areas are ticked for you: Identity and access, Service definitions, Notifications, Tables, Service catalog, Business rules and Approvals. Untick what the person does not need and Save. The areas are stored on the server; the page never holds its own list.
With both, every stage of the application’s Setup page is editable except the Assistant’s connections line, which stays with the Administrator.
Good to know
- Identity and access reaches the whole tenant. A Configurator with that area can create groups, add members and assign any role, including the Administrator role. Give it to the person who runs the desk, not to every application admin.
- Application admin roles do not carry tenant-wide capabilities on purpose. Incident Admin configures incidents. Teams, targets and notification rules are shared by every application, so they stay with the Configurator or the Administrator.
- A Configurator without an application role does not see the application’s records. The capability areas open admin pages and the tables those areas own; an application’s own tables need the application’s role.
- Every person has exactly one base role. Changing it replaces the old one. For a Configurator, the ticked capability areas are saved together with the role; a Configurator created without customizing holds every area except Identity and access and the external reach areas.
- The portal is open to everyone. A person with no application role can still raise requests; they see no internal module.
How it connects
The access model itself (identity from the signed token, capabilities per area, per-table access, tenant scoping) is Identity and access. The Setup page and its stages are in Configure an application. Every capability and the tables each area governs are listed in the capabilities reference. Who approves a plan an assistant proposes is the agent safety model.
- Give access through teams: Refine your service desk setup.
- Approvals in detail: Create an approval policy.