Roles and Access

This feature is currently available only to customers participating in a Private Preview. If you'd like to participate and be among the first to try this feature, ask our support or account team for details.

A role is a collection of resources and entitlements that can be assigned to new identities with similar access needs. Roles should be created with the basic access required for a specific job or function.

Role-Based Access Control (RBAC) is a foundational element of Identity Governance Administration (IGA), associating a user's role (for example: student, administrator, auditor) with their permissions or levels of access to an organization’s IT systems, software, and data.

Roles group specific resources (applications) and entitlements to simplify and standardize access management.

Example: A writing application may have a "Writer" role that allows users to edit and delete articles and a "Reader" role that only allows users to read articles.

By grouping resources and entitlements into roles, RBAC streamlines the access assignment process, making it easier to provision, manage, and revoke access as users join, move within, or leave the organization.

Role-Based Access Control

A Role-Based Access Control (RBAC) approach to managing access offers many advantages, including eliminating guesswork when making access decisions.

A well-defined RBAC model will specify exactly what level of access each role within the organization should have. The IT administrator doesn’t need to know all the details — only which role the user has, and the rest will follow automatically.

Even better, you can synchronize role information from an authoritative source which automates the whole process end-to-end. If your HR system is the authoritative source, you can synchronize a user’s job role from HR and map it to a role in RBAC.

Example: a new user is created in the HR system with a job role of ‘Financial Controller’ and they are automatically granted appropriate access to QuickBooks and Salesforce.

Scenarios without Role-Based Access Control

Working without RBAC might be acceptable for a small organization, but can rapidly create get out of hand and cause administrative challenges.

Consider a scenario where there are no roles defined. When a request for a new account comes in, the person creating the account must decide what level and type of access to grant, perhaps by:

asking the new user’s manager (in the hope that they know)
granting the same access as someone else in the same department or with the same job (though you we don’t know if that person has the right level of access)
giving them access to everything (which happens more than you might think)

None of these scenarios is ideal, and can quickly lead to access sprawl, creating significant problems with:

Security — because users may have more access than they need, and administrators have no real way of knowing.
Efficiency — because time and effort are expended trying to determine what access to provide what access someone actually has (for mandatory audits).

RBAC enables you to understand the varied access requirements across your organization, and helps prevent access from becoming a "free for all."

Working with Roles

Search for or navigate to the Access Model page.
Select the Business roles tab.
Create or modify a role using the field descriptions in the table below.

Field	Required	Data Type	Note
Role Name	Yes	Text (unique)	The name is used as the role’s identifier.
Description	Yes	Text	A text description of the role.
Manager	No	Lookup	Role Manager. This manager will be considered a secondary manager for any identities assigned to this role.
Is Auto Approved	No	Boolean	Allows identities to add this role to their account instead of initiating a request, which will have to go through an approval process. Note: If this field is set to true, the Owner and Owner Type fields cannot be configured.
Owner Type	No	Selection	Select a user or user collection. Selecting an owner type will allow you to select an owner.
Owner	No	Lookup	Once an owner is added, the selection can be edited or removed only until the role is saved.
Reason Is Mandatory	No	Boolean	When set to true, identities cannot request this role unless they provide a reason to accompany their request. When set to false, providing a reason when making a request is optional.
Assignment Collection	No	Selection	A policy that, when true, assigns this role.
Resources	No	Lookup	Resources assigned to this role.
Entitlements	No	Lookup	For each resource, any entitlements that are also granted by this role.

Updating a Role

The table below shows the editing limitations of an existing role.

Role Name	Limitations
Is Auto Approved	Cannot be updated
Owner Type	Cannot be updated
Owner	Cannot be updated

Deleting a Role

When deleting a role, the system will check if the role being deleted is in use:

If the role is in use, you will be notified and won’t be allowed to delete the role.
If the role is not in use, it will be deleted.