Roles are used to designate responsible agents for workflow tasks. Roles can restrict possible agents based on organizational data, master data, customizing data, or distribution lists. Roles are defined to evaluate parameters like organizational unit, job, user, material, or customer and determine the responsible agent based on the parameter value. SAP provides standard roles, and custom roles can be created using SAP organizational objects and responsibilities defined for different parameter values or value ranges.
5. Selecting Users for Work Items Process Workflow Definition Organization Org. unit Job Position User ID Role function Previous workflow agents Worklist Responsibility Your worklist is offering you a view to all work items, where you are one of the recipients Business Workplace Prio Tasks Date Approve Form Mar 1 Post Invoice Mar 25 Post Invoice Apr 5 1 2 3
6.
7.
8.
9.
10.
11.
12. Role based on Organizational Objects Possible agents Edit Material Master transaction (basic view) Material: My_part Old Material: Original_part New_part Lab: PM1 Change documents ZBUS1001. Old_Material_changed Org-Plan Engineering unit Product Management unit SAP org object T024L PM1 Product Manager Position Holder: Jones Role: Find Lab Check table T024L Import parameter Display Material
13. Definition of SAP Org. Object Types PD-ORG O - Design Unit SO T024L / KB1 Position_1 -- USMeier BUS1001 virtual attribute Laboratory PM1 Object Type BOR O - Product Management Unit SO T024L / PM1 Position_2 -- USHinz Display ExistenceCheck Description Laboratory T024L T7791 T024L OrgObjTyp ObjTyp ... 0 ... ... ... Key Attribute Methods Events 1 2 3 4
14.
15.
16. Role Resolution and Binding Role parameters (definition) Binding from task container or workflow container Position Job User Parameter1 Parameter2 ... Role container Role parameters (runtime) “Input” Org. unit Master data Organizational plan Customizing data Result of role resolution Person Role resolution Function module for role resolution “Rules”
17.
18. Role Definition With Responsibilities: Example Mr Smith Position: Administrator 2 in HR dept. Ms Jones Position: Administrator 1 in HR dept. Employee names A - K Employee names L - Z Reponsible for Reponsible for
19. Role Definition With Responsibilities: Implementation Role container definition Container element Data type Description element Char 1 First letter of last name Responsibilities (or areas of responsibilities) Value from Value to Description A K Employees from A to K L Z Employees from L to Z Mr Smith Ms Jones Assigments
20.
21. Procedure to Select the Work Item Receiver Second : Evaluate the Step Role Resolution Fourth : Remove all excluded agents from the recipient list Third : Evaluate the Task Default Role, in case there is no step role If a user was determined by the role and s/he is also a possible agent, then this user is a recipient. If a user was determined by the role and s/he is not a possible agent, all possible agents will get the workitem First : Find possible agents (For a general task every user is a possible agent)
22.
23. SAP Workflow Course PwC Consulting TM refers to the management consulting services businesses of the member firms of the worldwide PricewaterhouseCoopers organisation. 2001 PricewaterhouseCoopers. All rights reserved.
Editor's Notes
31 During runtime the role resolution will determine the responsible agent(s) for a work item. All responsible agents, who are possible agents of the task, will become recipients of the work item. The workflow system will put this work item only once into the worklist. All recipients have a view to this work item by refreshing their worklist.
A dialog task has pre-defined possible agents. Only possible agents are allowed to execute the corresponding work item at runtime. Roles are used to obtain those users which are responsible for this step according to the runtime data. All responsible agents, who are also possible agents, receive a work item and are called recipients. There are several different possibilities to build a role. In addition to the list on this slide there are: ABAP function modules TS30200141 - pick selected agent at runtime Search through the organizational structure by using HR evaluation paths
In this scenario the three workflows are almost identical. They were created by three different student groups following the “vacation request” tutorial. Assumption - All three “Approve” steps are using the same role “157”, which will find the manager of the workflow initiator. Question - What happens if Bert would start all three workflows and then Fred would start them as well? Answers - Bert will successfully send his vacation request to his manager only by starting workflow WS99900030 and WS99900031. Bert's attempt to start WS99900032 will fail, since his manager is not connected to job C 5009876. Fred will successfully send his vacation request to his manager only by starting the workflow WS99900030 Fred's attempt to start WS99900032 will fail, since his manager is not connected to job C 5009876. Fred's attempt to start WS99900031 will fail, since his manager's position is S 50000013.
Example for a role resolution like it could be used in an “accounts payable” workflow. Design requirements - All clerks working in this unit are assigned to a special customer group. At runtime they should only receive invoices from those customers. Each clerk has a pre-defined personal transactional limit. If the invoice is above this limit, this clerk may not work on the invoice. Runtime - The two import parameters (“Manley Corp.” and 258,300$) for the role resolution will determine that the work item should be sent to those circled three red agents. Only those three recipients will have this work item in their worklist. The first user, who is executing the work item at runtime, will block the access to this work item. No other user has access to it anymore. The work item will actually disappear from the worklist of the other two users, when they refresh their worklist. After the 'first agent' has completed the work item, it will disappear by itself from the worklist after the next refresh.
Assumption for this example of a business process: The creator of the basic view of the material master is considered to be the material controller. Design-Procedure for the Material Controller Role: First - Assign the possible agents to the task. Second - Create a role which is returning the controller for a given material. This role probably has to be created by yourself: Copy an existing role function module (ABAP-program). Change this program, so it will find the creator of the imported material master. Third - Assign this role to your step definition and provide the import parameter. If you use the task stand alone, you can assign the role directly to the task. During runtime this role resolution will return a special user ID. This user will become the recipient, only if she/he is also a possible agent of this task. If there is an error during the role resolution, then the setting of the role termination flag will determine how the workflow will continue: flag is “on” - the workflow will stop and only one message is sent to the workflow administrator. no flag - the workflow will route this workitem to ALL possible agents!
SAP is providing Organization Object Types. These can be used to establish a new dimension in your existing organizational plan. First : Check transaction PFOS to find a suitable “Organization Object Type”. In this case the T024L “Engin./design dept.” is a good fit for this business process, because the business object type BUS1001 (material master) has a connection to objects of this type T024L. This connection is established by the attribute BUS1001.LABORATORY (Test this attribute, or build such an attribute.) Second : Assign an object of T024L to the organizational plan. Third : Build a role, which is based on Organization Object Types T024L. Fourth : Assign this role to your single step task or your step in the workflow. Provide the attribute BUS1001.LABORATORY as an import parameter to this role.
Definition: Definition of the object type which is to be used as the SAP Org. Object (T024L in this case). Definition of an attribute for the object type in your workflow container. (BUS1001 in this case). This attribute has to be a virtual attribute which is based on the SAP org. object type (attribute Laboratory in this case for object type BUS1001). Definition of the BOR object types as SAP Org. Objects in PD Org and specification of the possible links in the Organizational Model via an entry in table T7791 (in this case, T024L may only be linked with OrgObject type O, i.e. organizational units). Linking an instance of an SAP Org. Object with an organizational unit from the Organization Model (in this case, linking laboratory KB1 with the organizational unit “Design Unit” and laboratory PM1 with the “Product Management” unit). Runtime: Since the role input parameter was BUS1001.Laboratory, the role resolution is scanning the whole org. plan for units, which are connected with this object of type T024L. The holders of positions in those units will be the recipients, if they are also possible agents of that task. Hint: You will receive the most flexible use of this mechanism, if you define the task as a general task.
T7791 can be viewed with transaction SM30. Maintenance of organizational structure from SWLD. Every business object may become a SAP org. object. Examples for engineering change management workflow business object ECM org. object TCC11 role AC00000138
Binding in the step definition between the workflow container and the (implicit) role container: The attribute which is contained in the SAP Org. Object (BUS1001.Laboratory in this case) must be assigned to the role container.
Some roles are supplied by SAP. A role is identified by a unique name. A role container is defined for each role. The role parameters establish which information is required for the role resolution to be executed at runtime. The role container is filled via a binding definition from the task container, if the role is used as a default role. The role parameter container is filled via a binding definition from the workflow container, if the role is used as a responsibility of a workflow step. Role resolution role resolution using master data evaluation paths in organizational management function module for role resolution (programming) In workflow projects you will sometimes have to create your own roles.
This type of roleis to help the application to solve probelems, such as finding the person respoonsible for a material, without seperate tables and role function modules. An assigment table is evaluated for role resolution, in which the various instances of the role parameters are assigned to objects of Organizational Management (jobs, positions, users, organization units) If you create a role of this type, you must: maintain the elements in the role container maintain the responsibility for each possible value/value interval of the role parameter(s) in the assignment table Assign agents (those reponsible)( to the values/value intervals Advantage of role definition with reponsibilities: if an organizational object is deleted, the roles of this type are also updated where-used lists for organizational objects also find these roles no ABAP programming is required
The two administrators are responsible for employee queries in a medium-sized business: Mr. Smith for employees from A to K Ms Jones for employees from L to Z
To create a role with responsibilites you must make the following entries 1. Role container: In this case we create an element with a length of 1 character, into which the first letter of last name is transferred at runtime 2. The areas to which agents can be designed must be defined in this case the areas ‚employees from A to K‘ and ‚employees from L to Z‘ are created 3. The area ‚employees from A to K‘ is defined by defining the interval into which the values must fall at runtime in order to belong to this area of responsibility. Likewise for area employees from L to Z‘. 4. Finally, the responsible persons are assigned: use button ‚insert agent assigment‘ What happens at runtime: The role just defined is called and receives a value for ‚element‘ If the current value is between A and K, Mr. Smith is the selected agent If the current value is between L and Z, Ms. Jones is the selected agent
Example of a special scenario Your workflow is very dynamic and the responsible agents for some steps cannot be determined at design time at all, but within your workflow every user will know to whom the next step should be delivered to. You can use the task TS30200146 to provide the possibility for manually choosing the responsible agent of one of the following steps. This following step must have one or more possible agents, for example one or more organizational units, positions, jobs or a list of user IDs. The task for the following step (“TS500000xy”) may not be defined as a general task. During runtime the user who is executing the work item for the first step may choose among the list of possible agents of task TS500000xy. All those manually selected responsible agents are transferred in the agent list to the next step. The work item of the next step is now available for all users, which have a connection to the elements of the agent list.
Only recipients, which are still on the list after the fourth step, can execute a work item. Most common error The dialog task has no possible agents assigned to it (In this case, there can never be a recipient!). You have to assign possible agents to all dialog tasks, even to those in delivered workflow templates.