Exploring Tasks, Rules and Responsibilities

• SAP S/4HANA Utilities contains various tasks that correspond to the normal criteria for agent determination.
• Once a task has been defined, you can allocate potential agents to it.
• You can use rules to modify individual assignments of potential agents to tasks. E.g. it is possible to use the same rule for different tasks if the same agent determination logic applies.
• If the predefined parameters do not cover company-specific agent determination, the enterprise can define its own rules.

• The task group is an object that you use to group several tasks for workflow purposes. You use it to efficiently group together different kinds of tasks in one job.
• You group together standard tasks (single-step tasks) and workflow templates (multi-step tasks) in task groups. You can allocate task groups to an existing task group hierarchy. You can allocate agents to individual tasks and/or task groups. The hierarchy structure of task groups means that when you allocate an agent to a task group, he/she inherits all sub-task groups.
• Standard tasks and workflow templates are standard objects that are delivered from SAP. The task group is also a standard object. It is neither time nor client-dependent.
• Before adding standard tasks and worklow templates to task groups, the reason for grouping them together must be clear.

• A single-step task identifies some processing action that needs to be done.
• In a workflow environment, the single-step task is the process that initiates work to be done by either submitting the work request to the responsible application process or delivering the work request to individuals who will be responsible for carrying out the work order.
• A single-step task can be allocated to a logical work unit within a multi-task definition (workflow) that specifies the sequence of work. In this case, different applications and employees from different departments may be involved.
• The work item text is the text in the Description column of the integrated inbox.
• The long text can be the task description, the notification text for notification agents, or the notification text when deadlines are missed.
• The variable parts of the text are automatically replaced at runtime by accessing the attributes of the processed objects.

• Task profile: A task is allocated to agents indirectly through its association with the jobs, or, more rarely, through its association with the organizational units or positions in the organizational plan.
• Job: A task is associated with one or more jobs and therefore describes these jobs and determines the task profile. All positions and position holders associated with a particular job "inherit" the task profile of that job. In addition to the direct association between jobs and tasks, a job can also be allocated to one or more application components:
  • All tasks of this application component are then automatically added to the task profile of the job without the need to allocate each task individually.
  • Authorization profiles are automatically generated for all position holders derived from the job, which makes access to the functions of the allocated tasks possible.
• Position: Tasks can also be allocated at the position level in order to give individual positions a task profile that differs from that of its associated job.
• Person-dependent allocation: Allocations that relate to a single person should be avoided in the definition period. This type of allocation is inflexible and requires more maintenance, for example if the employee is transferred or absent.

• Before you can add positions to your organizational plan, you must define a corresponding job. All the positions described by the job inherit all the tasks that you have assigned to the job. The job can be thought of as a "description" of the positions.
• Jobs are not fixed elements of the organizational plan, so a job can be used as the basis for positions in several different organizational units (for example, the position "Agent" can be used as the basis both for a position in the organizational unit "Customer Service" and for a position in the organizational unit "Accounting").

If every position derived from a particular job is to involve carrying out the same task, it is recommended that you assign that task directly to the job.

• If you assign a task to a job, all the positions derived from it (and therefore the specific job holders themselves) will "inherit" this task. This is also true for all positions derived from a job, whatever organizational unit they belong to.
• You can also allocate a task to an organizational unit. In this case, all positions of this organizational unit "inherit" the task.

You can also assign a task to an individual position (and thereby to a particular job holder), if that task is to be carried out by the holder of that position only. You can also allocate a task directly to a job holder. However, this requires a lot of maintenance in the case of a change in personnel.

• Examples of current application data that you can use as a criterion in rule resolution are:
  • Company code
  • Division
  • Billing class
  • Regional structure group
• In addition, you are free to define criteria of your own in a customer-defined task (the first letter of customers' last names, for example).

• Responsibility rule type: An assignment table is evaluated in which Organizational Management objects (jobs, positions, users, organizational units) are assigned to the different instantiations of the rule parameters. Agent determination is carried out in IS-U using this rule type.
• Organization data rule type: Organizational units such as MRP controller, planner group, shipping point, or sales office are used in rule resolution. This special type of clerk determination is not recommended for IS-U.
• Function to be executed rule type: Rule resolution occurs via function modules. If agent determination is not possible using the rule type responsibility, then customer-specific function modules can be used (by means of this rule type).

• If you want to use current application data as a criterion in agent determination, you must use rules belonging to the responsibilities category.
• If agents are to be determined using only the task as the selection criterion (when a bill document is to be posted, for example), allocation of a rule is not necessary. In this case, agents are allocated directly to the task. The number of agents responsible is then the same as the number of potential agents.

• In the rule, you define the criteria by which an agent is to be determined (company code, for example). You use the responsibilities to narrow these parameters down further using specific data from the application (company code U100, for example). In other words, the general criteria for agent determination (rule parameters) are defined in the rule, whereas the responsibilities determine the specific instances of these criteria that will actually determine the agent(s) for the task.
• For example, the agents responsible for meter reading are to be determined using the criteria company code, division, and regional structure group. These parameters are defined in the task container. As agent determination is to take place using current application data at runtime, a rule belonging to the responsibility category is also required. Before you can link a task with a rule, the rule container must have the same parameters as the task container. Appropriate responsibilities are created for the rule, with reference to the relevant application data (rule resolution). By combining a number of possible entries, you can make the selection criteria extremely specific. You can also specify value ranges in the responsibilities (for example, company code 01 - 03) and use wildcards (*) for a generic search in agent determination (responsibility for all regional structure groups, for example).
• One rule can be used by a number of tasks: the CSR rule, for example, is linked to the two tasks "Post document" and "Read meter". The criteria for determining agents for the two tasks are therefore identical.

• In the example in the slide, the task and rule containers must contain the following parameters:
  • Customer name
  • Bill amount
• In the responsibilities assigned to the rule, these parameters are narrowed down further using the clerk determination criteria defined, to produce the following rule resolution:

Every change to the parameters for the task or standard rule represents a modification. If you still want to change the parameters, you can copy the task and make your own modifications on the copy. In Customizing you link the copied task to the original task.