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