What are TAP Permissions?
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.
Learn more about editing, enabling, disabling roles and permissions on this page.
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.
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.
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.
Glossary of Permissions
The glossary below details the Administration and Workflow permissions within TAP.
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)||
This allows the user to have the “View Audit Trail” or “View History”, since any of the three allow you to have this privilege.
|Delete items Privileges||Allows a user to delete an item from the workflow record (conditional)||
Intel: If you have Allow Create with the proper workflow permissions, you can delete items. However, if you instead have both Allow Create & Allow Update, then you do not need the workflow permissions. Meaning that as long as you have access to view a workflow you can delete it, regardless of the workflow permissions.
|Document Library Privileges||Allows a user to see and/or upload a document to the Document Library.||
Visible has no use, however Allow Create allows you to upload and save new file. Edit allows you to edit the document library files, meaning you can change name, types, files, etc.
|Edit Items Privileges||Allows a user to view and/or edit a workflow record’s column data after it has been submitted||
If the user has proper workflow permissions, then having visible and only visible will be that you get “View” in the dashboard actions instead of the “Edit” option. However if you have Allow Create or Allow Update you will always get “Edit” as long as you have the proper workflow permissions
|Grid Data Source – Delete Item Privilege||Allows a user to delete a Grid Data Source.||
All three (Visible, Allow Create, Allow Update) allow the ability to delete items in Grid Data Source. If you have any one of the three, you will have this ability.
|Repository – All Records Privilege||Allows a user access to the All Records filter in the Workflow Dashboard. What constitutes All Records is conditional||
Have the “All Records” option in the left bar navigation on the dashboard. Only the Visible option affects this permission, Allow Create & update do nothing.
|Repository – Cancel Agreement||Allows a user to cancel an agreement (conditional)||
Both Visible & Allow Create add the cancel option to the signature repository. Allow Update has no use.
|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||
Visible has a use, it shows the export option in certain parts of the site (not confirmed which parts, Dashboard is assumed)
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.
|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).||This rule indicates which roles or departments (OR logic applied for Roles and Departments selection) can start a current workflow. If the 'make available for everyone' checkbox is checked, it indicates that any user in any role and any department is permitted to start a workflow.|
|Show audit trail for in process workflows||This permission allows users to see currently active (in process) workflow records that they are not currently assigned to in his/her Workflow Dashboard (if granted this permission as well as the Admin Repository – All Records Privilege).|
|Show audit trail for completed workflows||Typically only Super Admins can see workflows once they are completed. With this permission, users can see completed workflow records (if granted this permission as well as the Admin Repository – All Records Privilege) 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 throughout the life cycle of the record. The record is visible in both the All Records and My Records views.|
|Visible in Dashboard to Assignees||When checked, any user assigned to complete a stage in this workflow can see the workflow record in his or her Workflow Dashboard throughout the life cycle of the record beginning after the user was directly assigned. 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.|
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.