How does it work?Workflow basically consists of steps and tasks. When creating workflow (in transaction SWDD or SWDB in SAP), you are creating a chain of steps. In these steps, depending on the type of step, you will be adding a task. This can be either an existing task or one you created earlier. Tasks can be reused, steps can not.
Tasks need to be defined and assigned to a user. The user can either be the 'workflow user', which is the case for background steps (steps that can be processed by the system, without interference of a user, for instance setting the status of an object based on the outcome of earlier steps). The user can also be an actual user, for instance the manager of the user triggering the workflow, or maybe a group of users from a specific department in the organisational model.
Agent assignment to tasksWhen creating a task, you can specify which users are allowed to process the task. If you use this, you will need to be aware that the assignment in your development system could differ from the assignment needed in the production environment. For background tasks though, agent assignment is not needed.
When creating the assignment, you can choose to assign:
- Directly to a user, which I would not recommend, unless you are testing
- To a position in the organisational model, which is tricky, as the ID of the organisational unit might be different in production and development
- To an organisational unit, which is tricky as well
- To an authorisation role
You can also choose to classify the task as 'general task', which will allow any user to be assigned to the task. If from an authorisation perspective there is no need for strict settings, I would recommend to do this.
Agent assignment in stepsNow that we have assigned 'possible agents' in the tasks, we can assign the actual processors in the step. This can either be done again directly to user, organisational unit or position, or again to a PFCG role. Here you also have some additional options, such as
- 'Expression', where you use data from the binding (so from the workflow container) to retrieve the assigned agent.
- 'Workflow initiator', which is the person that triggered the workflow in the first place
- 'Superior of workflow initiator', which is the manager of the person that triggered the WF
- 'Rule', which can be any rule from the partner and organisation processing pool.
You should use expressions if the person to be assigned is already part of the workflow (for instance a previous processor of a task, or the workflow initiator)
You can use rules for all other (more complex) assignments.
Using organisational data determination rulesRules can be used for more complex agent determination.
Organisational rules available are defined in customizing:
SAP Customizing Implementation Guide - Customer Relationship Management - Master Data - Organizational Management - Organizational Data Determination - Change Rules and Profiles - Maintain Determination Rules.You will notice there are many rules, most of them for very specific tasks.
Rules basically consist of a container (which you can bind to from the workflow), and a function module. The function module will read the data from the container, and use this to determine the agent or group of agents.
There are a few useful function modules in the range CRM_ORGMAN_OBJECTS_FIND*.
For instance the CRM_ORGMAN_ORGOBJECTS_FIND_1 can be used to find organisational units with a specific attribute. At runtime, all organisational units that have this particular attribute will be found, and the task will be assigned to this unit.
In order for this rule to work, you will need to assign the attribute to the org unit you would like te be determined. You can use the standard SAP attributes, or you can create your own in transaction OOATTRCUST_DISP.
If you create a new attribute there, assign it to the org model, and create a new rule where the attribute in the container has the same name as the attribute that you have assigned to the org model, you can use this rule in your workflow to determine the organisational units based on the value of the attribute. When using this rule in the workflow, you should bind the proper value to the container attribute of course.