Authorization Control in XCM
Overview
XCM Authorization Control
Authorization control in XCM is managed through the following authorization objects:
/XCM/CR/XCM/CRCL/XCM/TR
Each authorization object has the single field ACTVT. The value assigned to ACTVT determines which function a user may perform, as described below.
1. Authorization Object: /XCM/CR
The authorization object /XCM/CR controls access to features related to Change Records and their associated processes.
| ACTVT Value | Function | Description |
PR | Process Correspondence | Controls the maintenance of the Process Builder. Only users with this authorization can change the Process Builder generated for a Change Record (edit, delete, activate or deactivate, and copy tasks; add or disable agents). |
23 | Maintain | Controls whether the decision table in Process Control BRF+ can be changed. Without this activity the decision table is read-only. |
PU | Publish | Controls the activation of changes made to the decision table in Process Control BRF+. Without this activity the activation is blocked. |
64 | Generate | Controls the generation of the Enterprise Search artifacts, including the search and result fields. |
CO | Complete | Allows users to complete the MDG request linked to the Change Record. |
Note: The object also allows further activity values. They are currently not checked by XCM: they are either reserved for future use cases or were put on hold due to Clean Core restrictions, and can be ignored for now.
2. Authorization Object: /XCM/CRCL
The authorization object /XCM/CRCL controls classification in Change Records:
- Assigning or removing a classification class.
- Changing characteristic values.
- The Classification Class value help in Extended CR Search.
Prerequisite: The checks only apply when the Classification Control switch is active and the record type has an active XCM process version. Otherwise classification in the Change Record is not restricted by XCM.
| ACTVT Value | Function | Description |
02 | Change | Unrestricted classification. With 02 the user can assign or remove any class and change any characteristic value in a Change Record. Without 02 the user can only use the classes that are marked as allowed for the record type in the allowed-class customizing (table /XCM/CR_CLF_CLASS); assigning, removing or changing values of any other class is rejected with an authorization error. |
03 | Display | Extended CR Search: Classification Class value help. The user needs 03 to see classes in this value help. The value help then shows only the classes allowed for the record types the user is authorized to display (/IAM/IAUTH, application CR, activity 03). Without 03 the value help shows no classes. |
3. Authorization Object: /XCM/TR
The authorization object /XCM/TR controls access to the Mass Upload of Teams and Responsibility app.
| ACTVT Value | Function | Description |
01 | Create or Generate | Controls who can create a new upload. Uploading the file, processing it and creating the Teams in bulk all happen within such an upload. |
V4 | Delete Version | Controls who can clear the upload history maintained by the app (Clear History action). |
XCM BAdI Implementations for Authorization and Process Control
1. Process Builder Authorization Control
To override the authorization control enforced by the authorization object /XCM/CR (ACTVT PR) when maintaining the Process Builder of a Change Record, implement the BAdI /XCM/PR_EX_PROCESS_BUILDER (interface /XCM/PR_IF_ACTION_CONTROL).
The BAdI has one method, PROVIDE_ACTION_AUTHORIZATION. It receives the Change Record details and returns one flag per action, which allows or forbids that action:
IS_EDIT_ALLOWED– Edit a taskIS_DELETE_ALLOWED– Delete a taskIS_ACTIVATE_ALLOWED– Activate or deactivate a taskIS_ADD_AGENT_ALLOWED– Add an agent to a taskIS_DISABLE_AGENT_ALLOWED– Disable an agent of a taskIS_COPY_ALLOWED– Copy a task
2. BRF+ Decision Table Governance and Email Notifications
With the governance feature for the BRF+ decision table described in point 1 of 2026.1.0 - Governance for BRF+ and XCM customizing, MDG cockpit, the users responsible for activation are notified by email. To determine these users, implement the BAdI /XCM/EX_BRF_ADMIN (interface /XCM/IF_BRF_ADMIN).
The BAdI has one method, GET_ADMIN_DETAILS, which returns the users who receive the notification.
3. MDG Request Completion for Change Records
To perform validations before completing the MDG request of a Change Record, or to execute actions after its completion, implement the BAdI /XCM/CR_EX_COMPLETE_MDG_REQ (interface /XCM/CR_IF_COMPLETE_MDG_REQ).
This BAdI provides two methods:
BEFORE_COMPLETE_MDG_REQUEST– Executes logic before the MDG request is completed.AFTER_COMPLETE_MDG_REQUEST– Executes logic after the MDG request is completed.
Keywords
record type, Change Record, authorization, authorization object, ACTVT, classification, Extended CR Search, Process Builder, BRF+, BAdI