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 lifecycle.

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 the task is opened. 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. In addition, the task is removed from the task list of all other potential owners.

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

In case of active principal propagation the principal information of the actual owner is propagated in the process flow and can be later consumed by an automated activity.

More information: Principal Propagation, 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.

More information: Configuring BPM Users

Contributors to Tasks

The actual owner of a task can invite at runtime other contributors to work on this task instance. Every user can be a contributor, except excluded owners. Contributors to a task can see the whole process context. They can monitor the task execution, can add notes and attachments but cannot complete the task instance. Users who are invited to contribute to a task receive the task in the universal worklist (UWL). When contributors open the task, they see who the actual owner is and the task description, if any.

More information: Sharing a Task

Business Process Administrators

A business process administrator can execute administration tasks for processes, activities, or tasks.

Possible categories of administration tasks to influence the process flow:

If you do not assign a business process administrator, the above mentioned tasks are available to the technical administrator only, who is assigned to the role SAP_BPM_SuperAdmin.