Role-based access control for Review Center

Each use case includes an rbac setting that determines how the Review Center controls access to documents. Use this setting to enable role-based access control (RBAC) for a use case or to continue using the legacy access model.

The rbac setting supports these values:

• rbac = true: Enables RBAC for the use case. The Review Center enforces the RBAC rules defined for the use case, and only users who match a configured rule can access documents. If no RBAC rules are defined, users cannot access the use case until at least one rule is added.
• rbac = false (default): Disables RBAC and uses the legacy access model. All authenticated users can view the use case. Access to documents is controlled by the document users list, as in previous releases.

Consider these points when configuring the rbac setting:

• Configure RBAC independently for each use case. RBAC can be enabled for some use cases and disabled for others.
• The rbac setting is the only setting that determines whether RBAC or legacy access control is enforced for a use case.
• Users assigned to the RPA-ADMIN role can access the RBAC configuration page at any time and define RBAC rules before or after enabling RBAC.

After an upgrade, existing use cases retain their current access behavior. Use cases with rbac disabled continue to use the legacy access model, and existing user access remains unchanged.

The rbac setting is defined for each use case and determines whether the use case uses RBAC or the legacy access model.

This example depicts a use case with RBAC enabled:

{

"usecaseName": "Invoice Approvals",

"version": "1.0",

"rbac": true

}

This example depicts a use case that uses the legacy access model. A use case uses the legacy access model when rbac is set to false or is not defined.

{

"usecaseName": "Purchase Requests",

"version": "1.0",

"rbac": false

}

An RBAC rule contains three main components:

1. Principal (Who)

   A principal identifies the user or group to which a rule applies. Each principal consists of a type and a value.

   A rule can contain one or more principals. When a rule contains multiple principals, all principals must match for the rule to apply. Principals within a rule are evaluated using AND logic. For example, a rule that includes both a user and a security role applies only when the specified user is assigned that security role.

   A principal includes these attributes:

   • Type: Specifies the principal type. Supported values include USER, group types such as SECURITY_ROLE and ACCOUNTING_ENTITY, and Custom Master Data types.
   • Value: Specifies the user ID or group name to evaluate.
   • Display name: Provides a descriptive name for the principal.

   A rule cannot contain duplicate principals. A duplicate principal is a principal with the same type and value. The same principal can be used in multiple rules. When multiple rules match a user, the user's effective permissions are the combined permissions granted by all matching rules.

2. Permissions (What)

   Permissions define the actions that the principal can perform. Permissions are organized by use case category. Each permission entry specifies a usecase_category and a list of allowed actions.

   The following permissions are available:

   • view_document: Allows read and view access to the document.
   • edit_document_fields: Allows updates to entity fields through partial updates.
   • edit_table_data: Allows updates to table data through partial updates.
   • update_fields: Allows updates to both entity fields and table data. This permission also supports bulk operations such as reprocess, visibility updates, and user assignments.
   • submit: Allows full document replacement through a complete update.
   • archive: Allows archiving of the document.
   • move: Allows changing the document category.
3. Attribute conditions (required)

   Attribute conditions define document-level filters that determine the documents to which the rule applies. Each RBAC rule must include at least one condition.

   If a rule does not include conditions, the rule does not match any documents and the principal does not receive access.

   Conditions evaluate document data at runtime. For example, a condition can match documents where a field such as DIVISION equals a specific value.

   To apply a rule to all documents, set the grant_all_documents field to true. When grant_all_documents is set to true, the system ignores conditions and applies the rule to all documents in the use case type.

   Each condition includes the following attributes:

   • attribute_source: Specifies the source of the attribute. The current supported value is DOCUMENT_ENTITY.
   • attribute_key: Specifies the field name in the document entity schema.
   • operator: Defines the comparison logic. Supported operators include:
     • EQUALS: Case-insensitive exact match
     • NOT_EQUALS: Case-insensitive not-equal
     • IN: Matches when the document value is in the provided list
     • NOT_IN: Matches when the document value is not in the provided list
   • value: Specifies the value or list of values for comparison. For IN and NOT_IN, the value is an array.
   • logical_operator: Connects multiple conditions using AND or OR

The system evaluates conditions sequentially from top to bottom. The system does not apply operator precedence. For example, evaluation of A AND B OR C occurs as (A AND B) OR C.

If a condition references a field that does not exist in the document data, the system evaluates that condition as false.