Use Cases for Apps with Authorization

By default, a user is allowed to run all apps that have been created in a project stored in one of his profiles. However, there are use cases, for example in approval workflows, in which you want to assign different authorizations: Certain process steps should only be executed by a defined group of people.

For example: When making a request, the requester should only be allowed to create requests. The approval levels should be reserved for users with approval authorization.

The following basics apply to working with role-based apps:

  • Creating Roles: When modeling the EPC, you define which role(s) are allowed to execute a particular process step. To do this, append the EPC element Role to the corresponding Function.
  • Assigning Roles: Roles and users are managed centrally in the Scheer PAS Administration. Here, the administrator can assign a role to all users who should hold this role.
  • Activating the Role Check: Every role needs own start links: Process App - Create and a corresponding Process App - Overview. In the settings of both elements, the designer must specify the role he wants to use (option Role For Link) and activate the role check in the settings of the element Process App - Create.
  • Creating Tiles in the Scheer PAS Cockpit: Users can create start tiles for each role in the cockpit which allows them to directly access the process step released for their role.

These steps also apply to the use of roles in Mobile apps. For execution on a mobile device, the start links Mobile App - Create and Mobile App - Overview must be equipped with the corresponding roles. The role check is managed on the element Mobile App - Create.
The role check does not apply to overviews. Basically all users are allowed to open overviews. Create specific overviews for each role using search queries or restrict user rights using the role rights option.

General Information

The elements Process App - Create and Mobile App - Create are used to manage the role check. The designer must also specify the role for each link (option Role For Link).

Use the checkbox Activate Role Check to activate and deactivate authorizations for specific roles.

In field Role For Link, enter the name of the role for which this start link is configured. 

You need a Create and an Overview start link for every role.

If the role check is deactivated, any user is allowed to execute the app. However, users can only execute apps stored in one of their assigned profiles.

If the role check is activated but no role has been specified in the Process App element, the user can also run through all process steps.

If a user tries to use a start link for which he is not authorized, the following message appears:

Permission Check
You are not authorized to execute the current process step.

Within a parallel Execution (AND Branching), the following message is used:

No Current Steps
Currently no further modification is required by your role or you are not authorized to execute the current process step.

The message indicates that the user is either not released for the current step - or that he has already processed all his steps within the parallel execution.

Expert Advice

Design users can not only use the app, but also edit it. For test purposes, it may be useful for the modeler to be able to run through all the steps of an app without having to change the user role.

To do so, create two "Designer start links" (Create and Overview) and deactivate the role check for these links. As a designer, you can now run through all process steps without having to create your own designer role.

If you also activate the option Hide in Cockpit, other users are note able to create tiles in the cockpit for the designer start links. This guarantees that only users with modeling authorization can run the app without role check.

Important note: When testing role-based apps, you should always test all start links and not just run the app as designer!



Important Notes and Tips

Important Note for Transporting Apps with Roles

Roles are managed centrally in the administration. When transporting role-based models from one system to another (for example, from a test system to a production system), you must ensure that the roles are also imported to the relevant administration. Further information on this topic can be found in the Administration Guide > Reusing Central Roles.


On this Page:
Related Pages:
Related Documentation:
  • No labels