Show TOC

Background documentationProcess Roles Locate this document in the navigation structure

 

A process role defines a set of rights and obligations for principals. Principals are assigned to process roles. Permissions are assigned to process roles. Principals as members of roles acquire permissions to perform an action on one or more objects. Objects are, for example, tasks and processes.

Within the SAP NetWeaver platform various roles already exist, for example, UME (User Management Engine) roles and portal roles. These roles define a set of authorizations for static content. Process roles are used for allowing a dynamic role based access control for artifacts available during a process life cycle.

More information: UME Roles and Portal Roles, Authorizations and Roles

Processors

In SAP NetWeaver Business Process Management (BPM), we can define processors at task, human activity, and lane level:

  • Task processors

    The task processor can only execute the particular task he or she is assigned to.

  • Human activity processors

    The processor who is assigned to a human activity overrides the task processor. This allows there to be different processors for a task because the task as reusable entity can be assigned to multiple human activities. Another processor can be assigned to each of the activities.

  • Lane processors

    The processor who is assigned to a lane can execute all tasks, which are assigned to human activities in this lane. The lane processor overrides the task and human activity processors. If you use a task within a process, the potential processor definition of the surrounding lane takes precedence.

The following table shows the order of precedence of the roles defined at task, human activity, and lane level.

Process Role Defined

Task

X

X

X

X

Activity

X

X

X

X

Lane

X

X

X

X

Applied Process Role

Lane

Activity

Lane

Lane

Task

Activity

Lane

For more information about the artifacts, see Using BPMN Process Models.

The processor is evaluated while the task instance is created at runtime. During this process, UME groups and roles are resolved into UME users. This means that changes to the group or role after the task has been instantiated do not have any effect on the task instance that is currently being created. If a user is assigned to a group or role that allows the user to execute a task during the task instance creation, the user could continue to work on the task and complete the task even if the assignment to the group or role is changed or canceled. These changes only take effect on the future task instances.

Caution Caution

Every user who works on any task in the process, can see the whole process context.

End of the caution.
Potential Owners

To define processors of a task, an activity, or a lane, you set them as potential owners. This means that the assigned processors are authorized to execute the task that is displayed in their universal worklist (UWL). A potential owner becomes the actual processor only when she/he opens the task. In the process composer you define the possible processors and give them the authorization to execute the task. When one of the potential owners claims the task, this user becomes the actual owner and therefore the processor of the task. The task now has the status 'in progress' and is displayed in the inbox of the actual owner only. The task is removed from the inbox of the other potential owners.

The following table shows in which status the task is shown in the inbox of the potential owners and the actual owner:

Status

Potential Owner

Actual Owner

New/Ready

X

In Progress

X

Reserved

X

Completed

X

The user who claimed the task can also return it to the pool in case they claimed the task by mistake or cannot complete it for any reason. After revoking a task, the task is in the inbox of all potential users again. For more information, see Delegating and Revoking Tasks.

You can find out the actual owner of a task instance with the Manage Tasks application in the SAP NetWeaver Administrator Operation Management. For more information, see Managing and Monitoring the Tasks.

You define potential owners at task level in the task editor, and at human activity level and lane level in the properties. For more information, see Defining Potential Owners.

Excluded Owners

Excluded owners are principals excluded from processing a task in the process model. This is required so that you can exclude users from approving their own request.

Example Example

A purchasing order process model contains an Order Request task and an Order Approve task. The requester and the one who approves the order should be different persons, that is the requester is excluded from processing the approval task.

End of the example.

You define excluded owners on task level in the task editor, and at human activity and lane level in the properties.

More information: Defining Excluded Owners

Accessing Tasks in the Universal Worklist

To enable users to access tasks in the universal worklist (UWL) and to execute tasks within a BPM process, you need to assign BPM portal roles to them. For more information, see Configuring BPM Users

Business Process Administrators

A business process administrator can execute administration tasks for processes, activities, or tasks. At least one administrator must be available for each process. A process cannot be deployed without an administrator.

Possible categories of administration tasks to influence the process flow: