Agents and Organizational Structure
Understanding Agents
An agent is the person responsible for executing the work in the Workflow. Each work item (understood as the runtime instance of a workflow step) can be processed by:
- The workflow system, using the user WF-BATCH.
- An agent.
Agents are responsible for executing tasks that cannot be automated. One of the most interesting tasks and typically one of the most time-consuming when defining a workflow is how the system should select the correct agents for executing each work item. From a business perspective, this is not trivial, particularly when it's a new process that has not been carried out before.
Agent Assignment
The workflow system must work with groups of agents to determine the final responsible parties for executing a work item. When designing, implementing, and maintaining a workflow, we must understand how the workflow system views these agent groups.
The agent groups are:
- Possible agents: These are the individuals allowed to execute the work. They are always assigned at the task level, upon which many work items will be based, but not to a specific work item itself. If a person is not in the possible agents group, they can never execute the task. Additionally, a task can be marked as general. In this case, all users will be possible agents for the task.
- Responsible agents: These are the ones we want to execute a specific work item. They are commonly assigned when creating a step in the workflow builder. They can also be assigned through "roles" or "positions" at the task level. With roles, responsible agents are dynamically assigned at runtime. They are always possible agents.
- Excluded agents: These are the individuals we do not want to execute a specific work item. They are always defined in the workflow builder when creating a step for a task.
These three groups can overlap and intersect to determine the final responsible agent.
Receivers
These are the individuals who automatically receive a work item in their inbox when the workflow creates the work item. They are also known as "selected agents." Receivers are:
- Possible agents for a task.
- Restricted to the list of responsible agents for a work item.
- Not members of the excluded agents list.
Consider:
- If there are no possible agents, NO ONE will receive the work item.
- If no responsible agent is defined in the step, the system will look for the default rule of the task. If there is no rule, all possible agents will receive the work item (excluding excluded agents).
- A receiver can forward a work item to another user. In this case, several possibilities exist:
- General Task: Work items can be forwarded to any user.
- General Forwarding Allowed: Work items can be forwarded to any user (but there is a list of possible agents).
- General Forwarding Not Allowed: Work items can only be forwarded to possible agents.
- Prohibited Forwarding: Forwarding work items is not allowed.
- The forwarding possibilities are defined within the task when determining the possible agents.
Other Agents
- Current Agent: While a work item is being processed, the current agent is the one processing the work item (has it taken). Once the work item is completed, the current agent will be the one who processed the work item last.
- Multiple Assignment: It may occur (and is very common) that the same work item is sent to several receivers. When one of the agents takes the work item, it will disappear from the inbox of the others, and in case they leave it untaken, it will reappear for all users.
- Deadline Agents: These are the ones who will receive a work item that has expired, meaning a deadline was set, and the deadline was reached.
- Notification Agents: These are the ones who will receive an email informing them that a certain work item has been executed successfully.
Organizational Structure in Agent Assignment
Every agent in the workflow system must have a SAP user ID. Every time we assign a possible, responsible, or excluded agent, we are implicitly assigning a SAP user. Maintaining user by user all the agents is an excessively tedious task since there can be multiple workflows, multiple users, etc. We must also remember that users are people and as such change positions, leave the company, new ones enter, etc.
Whenever possible, we should maintain the assignment of users to workflows through an organizational plan or organizational structure.
The Basic Organizational Plan
The basic organizational plan consists of a series of relationships, represented as a hierarchical organizational structure between different organizational elements such as:
- Organizational units: each organizational unit represents a group of people like a team, department, section, work area, laboratory, etc.
- Jobs: a job describes a functional role within the organization.
- Positions: each position represents a place to be occupied by a person, it's a physical desk or a vacancy.
- Users: it's the SAP user assigned to the position.
Most organizational objects have a code, a description, and a validity period. By default, the validity period is assigned with the date of the object's creation and as the expiration date will be December 31, 9999. However, the period can be changed.
Maintaining the Basic Organizational Plan
To create an Organizational Plan or Organizational Structure, we access transaction PPOCW and select a validity date. Then we perform the following steps:
- Creation of the organizational unit: to do this, press the create button, select the organizational unit, and enter a code, a description, and a validity period.
- Creation of the function: from the menu, select "deal / create functions" and enter a code and a description.
- Creation of a position: enter the code, description, a function, and whether the position is or is not the maximum responsible for the organizational unit. We can also enter validity.
- Assigning a user: Place the cursor on the position and press the assign button. Then select "holder" and choose a user, for example, ours. Finally, change the position description.