Skip to main content
Roles allow you to segment access to organization information or the different platform features based on the user who has signed in and the role they have applied. Within the same role, you can assign different permission levels for different organizations. roles-list

Create a new role

To create a new role, click the New button. A form will open requesting a name for the new role. Once assigned, it will appear in the roles table.

Multi-tenant environments

An organization’s roles let you configure access and visibility for the organization’s users, and they also allow you to include permissions to configure access and visibility for dependent organizations. An organization is dependent when:
  • It is a customer-type organization and the roles and users are in the higher-level partner-type organization.
  • It is a sub-organization of a customer organization.
Roles are assigned to users and contain the definition of access and visibility levels, allowing you to set different configurations within the same role for the root organization and its sub-organizations. This can only be done in a top-down manner; that is, from a higher-level organization, permissions can be assigned to that organization itself and to the organizations that depend on it.

Table information

The roles table shows the following information:
  • Name. Name assigned to the role.
  • Assigned users. Users to whom that role is assigned.
  • Assigned tenants. Tenants to which that role is assigned.
  • Created by. User who created the role.
  • Updated by. User who updated the role’s information.
  • Created on. Role creation date.
  • Updated on. Role update date.
  • Action.: Provides access to View details and to Permissions.
If you click the arrow located to the left of the role name, a sub-table will be displayed from where you can access direct information about the permissions assigned to that role, as well as the tenants to which that permission has been assigned. grid-permissions

Details view

When you click on an item in the roles table, you go to the details view, which shows the following tabs:
  • Details
  • Permissions
  • Users
  • API keys

Details

This tab holds additional information about the role: name, number of users and tenants to whom that role has been assigned, creation and update dates, and the user who created it. At the bottom right, the Clone button allows you to copy and reuse the role. Edit provides the option to change the role’s name.

Permissions

Through Permissions you can view, create, or edit permissions. In this view, you can configure a single group of permissions for each selectable organization. New lets you create a new permission with the following information:
  • All tenants
  • Tenant
  • Permissions
  • All reporting groups
  • Reporting groups

All tenants

Lets you apply the permissions to all organizations you have access to. In service provider use cases, it allows you to manage permissions centrally and replicate the changes to the managed customer organizations. When a role’s permissions mix permissions applied at the “All tenants” level with organization-specific configurations, which may be different, the more specific permission wins. This way you can create a default configuration for all organizations and override those that require modifications.

Tenant

Lets you specify the organization to which permissions are being granted in the role being edited; the All tenants option lets you configure the role’s permissions to apply to all organizations you have access to.

Permissions

Lets you select the access level the role will have.

All reporting groups

Lets you apply the permissions to all reporting groups you have access to. In service provider use cases, it allows you to manage permissions centrally and replicate the changes to the managed customer organizations.

Reporting groups

Lets you apply the permissions to the specified reporting groups; there can be more than one.

Users

This table lets you view the users who have the role assigned, and provides the option to perform searches.

API keys

Shows a table with the list of API keys created for that role. The fields contain the following information:
  • Name. Name assigned to the API key.
  • Status. Can be Active, Expired, or Revoked.
  • Key ID. ID corresponding to the API key.
  • Creation date. Date and time the key was created.
  • Expiration date. Date and time the key expires.
  • Revocation date. If it has been revoked, revocation date and time.

List of roles

The platform distinguishes the following roles:
AbbreviationRole
Org AdminOrganization administrator
Org Admin RORead-only Organization administrator
UserUser
L1Support team
L1 RORead-only L1 support team
L2L2 support team
L2 RORead-only L2 support team
L3L3 engineering team
L3 RORead-only L3 engineering team
BillingBilling

Permission tables by role

Roles let you group different access levels. The detail of the visibility and actions available for each role is defined in the following table:

Home

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read

Operations

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read

Audit logs

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read

Flows

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
Create⭐⭐
Modify⭐⭐
Delete⭐⭐

Reports

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
ListRead
DetailsRead
Create
Delete
SettingsModify
Create with AIRead
Create
Modify
Delete

Tenants

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete
ActivationRead

Monitor

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Active alertsRead
Alert settingsCreate
Read
Modify
Delete

Workspaces

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
Modify
Delete
Workspace groupsRead
Create
Modify
Delete

Updates

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
Create⭐⭐
Modify⭐⭐
Delete⭐⭐

Analyzer

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Installed applicationsRead
Modify
LicensesRead
Create
Modify
Delete
SAMRead

Microservices

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
EnabledRead
Modify

Billing

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
Modify

Product

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
ReportRead
EnvironmentRead
Modify
BaselineRead
FlexxAgent settingsRead
Modify

Integrations

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify

Webhooks

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete

Modules

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify

Information

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Read
Modify

Policies

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete

API keys

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify

Reporting groups

FeatureActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete
FlexxAgent settingsRead
Modify
Automatic updateModify
FlexxAgent versionRead
Modify
Magic linkCreate
Read
Modify

Roles

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete

Users

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete

DaaS

ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Create
Read
Modify
Delete
  • ✅ Has access.
  • ⭐ Has access if they additionally have L1 in Workspaces.
  • ⭐⭐ Has access if they additionally have L2 in Workspaces.
  • ❌ Does not have access.

Permission tables for microservices

The user’s role corresponds to the organization where the microservice was created.
ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Clone / create
View🔑
Edit💡
Change to public or private
Edit visibility when private💡
  • ✅ Has access.
  • 🔑 Has access if they additionally have read-only L1 in Workspaces.
  • 💡 Has access if they are the author of the microservice.
  • ❌ Does not have access.

Enabled microservices

The user’s role corresponds to the organization where the microservice was enabled.
ActionOrg AdminOrg Admin ROUserL1L1 ROL2L2 ROL3L3 ROBilling
Enable
Disable
Edit
  • ✅ Has access.
  • ❌ Does not have access.