Administration Level Permissions 

Administration Level permissions assign privileges to specific user roles within TAP at the site (system) level.

By selecting Application Visibility from the PERMISSIONS menu in the Administration module, you can establish which aspects of TAP are visible to which roles. By selecting Application Permissions, you can determine what functions different roles are able to perform in TAP.

Digging Deeper

Within the Application Permissions of the Administration tab, there are two different types of permissions. These can be roughly categorized as general site permissions and general workflow permissions. General workflow permissions must work with workflow permissions (found within a specific workflow) in order for the permission to have meaning. 

A general site permission is one that does not require access to a specific workflow. For example, the Grid Data Source – Delete Item Privilege is the permission to delete a Grid Data Source. It should be clear that one’s ability to delete a Grid Data Source has nothing to do with a workflow, either generally or specifically. Any role with a privilege like the Grid Data Source – Delete Item Privilege will be immediately able to wield such a power and delete as many Grid Data Sources as he or she might wish. The other type of permission found in the Application Permissions section can be roughly categorized as a permission that sets the stage at a general level but does not have an immediate impact– a general workflow permission. Only when a general workflow permission (found in the Application Permissions section) and a corresponding permission is set at the individual workflow level will the general workflow permission have any effect.

If a general workflow permission such as Repository – All Records Privileges is granted to a role, that role-bearer will still not be able to see any workflow records until he or she has also been given access to view the record of a workflow at the level of that specific workflow. Similarly, in the Application Permissions section of the dashboard, we determine whether or not certain roles have Audit Trail Items Privileges. This privilege is what allows for a given role to see a workflow’s Audit Trails by selecting the View History option in the Actions column. However, even if a role is granted this privilege, that role-bearer will be unable to view the Audit Trail unless there have been Audit Trail permissions configured at the workflow level as well. Whether or not a user is ever able to see an Audit Trail is configured in Application Permissions, and whether a user is able to see the Audit Trail for a specific workflow is configured at the department level in the workflow permissions section.

Workflow Level Permissions

Workflow Permissions are managed within each specific workflow (Business Automation > Designer > Workflow), and confer permissions to departments and roles. These permissions intersect with and may be dependent upon the permissions granted at the Administration level.

Although there is no hard and fast rule, the Administration-level privileges tend to operate on the site (system) level, while the Workflow-level privileges operate on the level of an individual workflow. The catch, of course, is that the ability to access a workflow may depend on your more general TAP privileges. 

Digging Deeper

Workflow permissions are assigned in the Designer, within each workflow, using the Permissions function. These permissions operate on the level of the individual workflow. For example, when we grant a department permission at the individual workflow level to Show Active Workflows, we mean that if the roles within that department are able to see All Records (as defined in the Application Permissions), then they will be able to see this record as well. We will refer to these permissions as specific workflow permissions.

Administration Permissions

There are a number of permissions within the Applications Permissions feature. Following are descriptions of the most important ones.

Workflow Permissions*

The Permissions feature in the Designer lets you set the specific permissions granted to users for a given workflow based on department affiliation or user role.

*Most workflow permissions are conditional upon being able to view these records, and therefore imply the Administration Permission “Repository – View All Records” OR the workflow permission “Visible in Dashboard to Requester / Assignees” has been checked.

Common Permissions

Audit Log Permissions

A Note On Stage Level Permissions

Stage level permissions allow you to further customize workflow permissions based on the stage a certain workflow has reached. When configuring stage level permissions, they function as a switch and not a static permissions setting. For example, if you have a linear three stage workflow and set stage level permissions on stage 2, both stage 2 and stage 3 will act on those permissions. However, if on Stage 3 you revert stage level permissions back to match the workflow level permissions, then Stage 2 would be the only stage with differing permissions. It's best to think of stage level permissions as an on/off switch where each configuration persists through all subsequent stages unless reverted with an additional stage level permissions configuration on one of the later stages. 

Under no circumstances should you set stage level permissions on every single stage of the workflow. This can cause issues with dashboard load and lead to long query times when filtering on different workflow records.