Hierarchy
GRCFND_A (Software Component) GRC Foundation ABAP⤷
GRC-SPC (Application Component) Process Controls⤷
GRPC_CUSTOMIZING (Package) Customizing
IMG Activity
| ID | GRPC_FALLBACKRECEIVE | Maintain Fallback Receiver |
| Transaction Code | S_GR1_31000089 | (empty) |
| Created on | 20071102 | |
| Customizing Attributes | GRPC_FALLBACKRECEIVE | Specify Fallback Receiver for Work Items |
| Customizing Activity | GRPC_FALLBACKRECEIVE | Specify Fallback Receiver for Work Items |
Document
| Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
| Document Name | GRPC_FALLBACK_RECEIVERWORKITEM |
Use
In this Customizing activity, you specify the user who is to receive a work item if the system fails to determine a recipient for a work item via the usual channels.
The fallback user must have sufficient authorization to deal with the different kinds of work items involved. We recommend that the fallback recipient be a user with super user or power user authorization.
Note: Ideally, although power user authorization must be assigned to the fallback recipient, it also involves the risk that the authorization entitles the user to view sensitive data of any kind from the RM and PC applications.
For more information, see the examples below.
Requirements
Standard settings
Activities
To maintain the fallback receiver:
- Choose New Entries.
- In the User column, enter a user with sufficient authorization; if possible, specify a user with super user authorization.
- Save the entry.
Note: We recommend that you create only one entry using this Customizing activity. The entry is valid for both the Process Control and the Risk Management applications.
Example
Example 1: Process Control
During business event configuration, a control tester was accidentally not assigned.
The Internal Controls Manager (ICMAN) has planned a manual test for a control, but the system cannot find the legal agent, that is, the workflow recipient.
In such as case, the assigned fallback recipient receives the task. However, if no fallback recipient is assigned, the task status is set as Error. Even though processing of the task can continue with the Error status, it is important to note that workflows with an error status must be actively called by the system administrator. This is because no workflow exists to notify the administrator about the errors.
Example 2: Risk Management
An incident is posted (in the system) for an organization; however no user with sufficient authorization to validate the incident has been assigned.
Without a fallback recipient, the status of the workflow for incident validation is set as Error, and therefore can no longer be processed.
If a global fallback recipient is assigned using this activity, the workflow for incident validation is sent to the fallback recipient's inbox.
Business Attributes
| ASAP Roadmap ID | 201 | Make global settings |
| Mandatory / Optional | 1 | Mandatory activity |
| Critical / Non-Critical | 2 | Non-critical |
| Country-Dependency | A | Valid for all countries |
Maintenance Objects
| Maintenance object type | C | Customizing Object |
| Assigned objects | ||||||
|---|---|---|---|---|---|---|
| Customizing Object | Object Type | Transaction Code | Sub-object | Do not Summarize | Skip Subset Dialog Box | Description for multiple selections |
| V_GRPCLASTRECIP | V - View | SM30 |
History
| Last changed by/on | SAP | 20100615 |
| SAP Release Created in | 250 |
