Practical Guide to SAP Workflow Agent Determination

2.1 Possible agent definition

Figure 2.2: Possible agent definition

Figure 2.3: Define possible agents on the task

Figure 2.2 shows the ways possible agents can be defined. The possible agents are defined from inside a task, as opposed to being assigned inside the workflow definition (see Figure 2.3). The possible agent assignment does not have access to the task container, and therefore, does not have instance-specific task data available for consideration. The possible agent assignment will be the same for every task instance. The objects assigned to it, however, can be dynamic, in that HR organizational objects are assigned to different users and role assignments are made independent of the workflow. Detailed next are the different ways the possible agents can be defined.

2.1.1 General task

A task may be defined as a general task, which means that every SAP user is a possible agent (see Figure 2.4). It is by far the easiest way to define possible agents, however, the time required for accessing the SAP Business Workplace takes a hit; it must evaluate all the open tasks. If it is a common workflow practice to make all tasks general tasks, there are a lot of tasks that must be read before the user can access their SAP Business Workplace.

Figure 2.4: General task

Whether your company uses SAP ERP HCM or not, you will have the following organizational objects available for making agent assignments to your task.

• Organizational unit
• Job
• Position
• Work center

Of course, there is a huge advantage when your organizational structure is maintained by your HR department in SAP. This means that with the new workflow you are rolling out, if you find an organizational unit or job to list as the possible agents, there will be less work to manage. For example, if you decided to use a rule with responsibilities, someone would have to maintain the user and responsibility assignments. Because the HR department is going to maintain the organizational structure, whether or not you have a workflow that uses it, you may as well take advantage of it.

Look at an example where you have a decision task that needs to be sent to customer service agents in central operations. Set up the possible agents in task TS 88700142 with the organizational unit O 50015524 (see Figure 2.5). Figure 2.6 shows transaction PPOM and the organizational unit with the task assigned to it. Another place to make task assignments to organizational objects is from transaction PPOM. By placing your cursor on an organization object and right-clicking on assign or by clicking on , you can assign a task here. Instead of having the ability to delete assignments from this transaction, you can delimit the relationship, which is actually a better practice because it will provide a history of the relationship.

Figure 2.5: Possible agents assigned via organizational unit

Figure 2.6: T-code PPOM customer service organizational unit

Additionally, you may assign positions as possible agents. This is not usually a good idea, although, it is certainly better to assign a position as a possible agent rather than assigning an SAP user ID directly to the task. This is because as personnel move in and out of the position, the agent determination will not need to change because the position that performs the task did not change, only the holder of the position.

It may make more sense to have your possible agents based on people in the company who have the same job. Figure 2.7 shows how a technician job is assigned to multiple positions across organizational units Western Operations and Central Operations. Figure 2.8 is an example of this job being used to define possible agents of task Customer Service Response.

Figure 2.7: Job—technician

Figure 2.8: Possible agents assigned via job

2.1.2 SAP system objects

Roles

Roles make the most sense for defining possible agents. You can make sure that the role contains the authorization to complete the workflow task. This will ensure that anyone who receives the work item as an original agent will have the authorization to execute it.

SAP user ID

It is not recommended to set up possible agents as specific SAP user IDs. This is the least-dynamic way to define possible agents and requires the most maintenance.

2.1.3 Tasks

Assignments via tasks is older functionality that is rarely used. If you select it, it is similar to a task group bringing in agents, but you can only use T tasks (customer tasks), as opposed to TS tasks (standard tasks).

2.1.4 Task group

Task groups provide a great way to group tasks that will all have the same agents. Take a look at an example of some auditing tasks. Figure 2.9 is the definition of a task group used for multiple auditing tasks. The auditing tasks were added to the Standard task tab. To maintain the possible agents for the task group, from the task group definition go to Extras • Agent Assignment • Maintain (see Figure 2.10).

Figure 2.9: Task group definition

Figure 2.10: Task group possible agent assignment

in Figure 2.10 shows the three auditor positions assigned to the task group. in Figure 2.10 shows the three tasks that were assigned to the task group on the Standard tasks tab. They automatically show up where agent assignment is maintained.

By maintaining the task group and making the auditors the possible agents for the task group, you have completed the possible agent assignment on all three of the auditor tasks. See an example auditor task in Figure 2.11 which shows the auditors assigned under the task group umbrella. The task group allows you to make changes in just one place, the task group, instead of setting up possible agents individually in the three tasks. This not only saves times, but helps ensure accuracy.

Figure 2.11: Task of task group agent assignment