Responsibility Rules in Workflow Configuration
Responsibility Rules in Workflow Configuration
In this note, I revisit the topic of workflows. This material can be seen as a logical continuation of my previously published post Finding the Task Processor in a Workflow, where I described how to locate the processor of a dialog task in a workflow configured for an appraisal document. Let me again emphasize that the processor was found with the help of ABAP—which is a perfectly acceptable approach when working with workflows (especially for identifying task processors).
An alternative method of defining the dialog task processor in a workflow is by using Rules categorized as Agent Determination: Responsibility. I will refer to this collectively as a Responsibility Rule. In the system, such a rule is represented by an object of type AC - "Rule". More about "Responsibility" below.
See also: Rules for Agent Determination for Tasks
Transaction for Maintaining Rules
The transaction for managing rules is PFAC.
When creating a Rule, make sure to specify its Category. You can find more detailed information about categories by selecting the Category field and pressing F1.
What is a Rule?
A Rule is essentially a decision tree. Based on input parameters, it helps determine who the task processor should be. These input parameters are passed via the Rule’s container, and the selected processor depends on the values received in this container.
What is “Responsibility” in Rule Configuration?
Once you’ve set up the Rule’s container, you need to define the Responsibility—in other words, specify who should approve the task depending on the container’s input values.
In SAP, a Responsibility is represented by an object of type RY - "Responsibility".
Example: Creating a Responsibility Rule
The video fragment shows an example of creating a Rule that accepts a Personnel Area as input. Different Personnel Area values are assigned to different processors.
Testing Rule-Based Processor Determination
To test your configured Responsibilities in the Rule, click the 'Simulate rule resolution' button. Depending on the input parameters in the Rule’s container, the system will assign a different processor accordingly.
Using Rules in a Workflow
Assign the configured Responsibility Rule to a workflow task that handles approvals, etc. A video below demonstrates this setup.
Testing Processor Assignment in a Workflow
According to the configured Responsibility Rule, the workflow should assign two different processors depending on the Personnel Area value. To test this, you’ll need to pass the relevant Personnel Area values into the workflow.
Ideally, the Personnel Area value should be automatically populated in the workflow and passed to the Responsibility Rule—for example, using a utility class.
For demonstration purposes in this post, I manually assign two different Personnel Area values as input to the Responsibility Rule, run the workflow with these values, and check which processor was assigned to the task.
Why Is This Useful?
Suppose you’re configuring a workflow for an appraisal document. The business users require that a responsible specialist approve the document first. However, due to historical reasons, the responsible specialists vary depending on the Personnel Area & Subarea.
A Responsibility Rule is the ideal solution for this. You create a Rule where the container consists of the Personnel Area & Subarea pair, and initially fill in the Responsibilities for the relevant container values.
A key advantage of Responsibility Rules is that once the functional consultant sets up the Rule and initial Responsibilities, the process administrator (end user) can independently modify Responsibilities directly in the production system using transaction OOCU_RESP.
If, for some reason, transaction OOCU_RESP isn’t suitable, you can create your own transactions based on FITP_RESPO or PTRV_RESPO as examples.
See SAP Note 534029 - Maintaining responsibilities in locked clients
Transactions OOCU_RESP or PFAC_RESPO are available for maintaining the client-specific responsibilities of a rule. PFAC_RESPO provides a predefined selection screen.
Using OOCU_RESP, you can create your own customizing transactions which automatically jump to the rule specified in each case and is able to maintain the responsibilities there. Transaction SE93 is available for this. A possible example would be transactions FITP_RESPO or PTRV_RESPO.