Skip to main content
Mitratech Success Center

TAP Permissions

Administration Permissions and Workflow Permissions determine privileges

Overview

Permissions in TAP determine who can do what, and when. Permissions operate at the Administration level as well as at the level of the individual workflow. Sometimes, these permissions overlap, and sometimes they do not. In this article, we’ll untangle these two types of permissions.

Administration Level vs Workflow Level

Administration Level permissions assign privileges to specific user roles within TAP at the site (system) level. The Super Admin role, for example, is configured in the Administration module. 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.

Workflow Permissions are managed in the Business Automation module, within a specific workflow, and confer permissions to Departments and roles. These permissions intersect with and may be dependent upon the permissions granted at the site level.

Workflow

Although there is no hard and fast rule, the Administration-level privileges tend to operate on the site (system) level, while the Workflow 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. There in lies the rub.

The Rub

Administration Privileges

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. 

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.

Application Privileges

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 Permissions

Workflow Permissions

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.

  • Audit Trail Items Privileges: Allows a user to view Audit Trails (conditional upon access to specific workflow audit trail).
  • Delete items Privileges: Allows a user to delete an item from the workflow record (conditional).
  • Document Library Privileges: Allows a user to see and/or upload a document to the Document Library.
  • Edit Items Privileges: Allows a user to view and/or edit a workflow record’s column data after it has been submitted.
  • Grid Data Source – Delete Item Privilege: Allows a user to delete a Grid Data Source.
  • Repository – All Records Privilege: Allows a user access to the All Records filter in the Workflow Dashboard. What constitutes All Records is conditional.
  • Repository – Cancel Agreement: Allows a user to cancel an agreement (conditional).
  • Repository – Download Agreement: Allows a user to download an agreement in the workflow record.
  • Repository – Export to Excel Privilege: Allows a user to export the dashboard to a Microsoft Excel file  – the content of his or her dashboard is conditional.
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.

Common Permissions
  • Allow to start workflow: Users can start specific workflows through the Workflow Dashboard (if granted this permission as well as the Admin Repository – All Records Privilege, the user will see the workflow record in his/her Workflow Dashboard).
  • Show active workflows: Users can see specific currently active (in process) workflows (if granted this permission as well as the Admin Repository – All Records Privilege, the user will see the workflow record in his/her Workflow Dashboard).
  • Show completed workflows: Users can see specific completed workflows (if granted this permission as well as the Admin Repository – All Records Privilege, the user will see the workflow record in his/her Workflow Dashboard).
  • Visible in Dashboard to Requester: When checked, the initiator of the workflow (the Requester) can see the workflow record in his or her Workflow Dashboard. The record is visible in both the All Records and My Records views.
  • Visible in Dashboard to Assignees: When checked, the user assigned to complete a stage in this workflow can see the workflow record in his or her Workflow Dashboard. The record is visible in both the All Records and My Records views.
Audit Log Permissions
  • Show comments: Users can view comments made in the Audit Trail in specific workflows.
  • Show and allow to add comments: Users can view, add, edit and delete comments in the Audit trail in specific workflows.
  • Show attachments: Users can view attachments in the Audit Trail in specific workflows.
  • Show attachments and allow to upload: Users can view and upload attachments to the Audit Trail in specific workflows.
  • Edit attachments: Users can edit attachments in specific workflows.
  • Show summary: Users can view the summary in specific workflows.
  • Show e-Signature documents: Users can see e-Signature documents in specific workflows.

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

  • Was this article helpful?