Aproove has a very flexible and powerful permissions model. There are 3 levels of permissions:
Permissions are granted to users or guests. Users with a login require a seat license, while guests do not and access the system via invitation only.
System-level permissions
This level of permission governs the actions that a user can take outside of the boundaries of a project. Only users that can log in to the system have system-level permissions. Guests do not have system-level permissions.
Examples of system-level permissions include:
Each user has a single set of system-level permissions.
System-level permissions
These permissions specify what users can do within a project when going through the project dashboard. Each project has its own set of permissions for each user. A specific user can have a different set of permissions for each project. If a user doesn't have any permission on a project, that project will be inaccessible to that user and it won't appear in the list of projects.
In the diagram below, User A has different permissions on Project A and B; and User B only has permissions on Project B.
Examples of project-level permissions include:
Task-level Permissions
These permissions set the rights that users and guests have when performing a task from their to-do list or from an email invitation. These tasks are usually sent via a workflow step, but can also be manually sent to users via the "Instant Share" or @mention functionality.
In the diagram below, note how User B has permissions on a task in Project A even though that user doesn't have any project-level permissions on that project. Also, note that guests can also have task-level permissions. Tasks are the only way that guests can access Aproove, so those are the only set of permissions that matter for guests.
Examples of task-level permissions include:
Roles can also be used for assigning metadata and Tags, but that is beyond the scope of the permissions model
Assignment of Permissions
Assignment of permissions is done via various entities within Aproove, depending on the permission context. This flexibility allows administrators to set up workflows that provide just the right set of permissions to the right users at the right time.
Groups
In Aproove, there are 3 types of groups:
Global groups are used to grant permissions. Schema groups allow administrators to organize users within a schema but don't come into play when setting permissions on projects. Contact groups are used to send tasks and don't grant any permission themselves.
Assignment of System-level Permissions
Only users can be granted rights at the system level. Most of these system-level permissions are granted via Global Groups. Certain system-level permissions are also granted directly to users, one by one in their individual settings. A user can be a member of many Global Groups and their resulting system-level rights come from the amalgamation of the rights granted by each of the groups the user is a member of along with the permissions directly assigned to the user.
In the diagram below, User A is a member of Global Group 1 and Global Group 2. That user receives the system-level permissions associated with both of those global groups. User B receives the system-level permissions assigned to Global Group 2 as well as the system-level permissions set directly on the user. 
Assignment of Project-level Permissions
Only users can be granted rights at the project level and each project has its own set of permissions. This means that users can potentially have different permissions on each project and that they might not even be able to see some projects.
Projects can either store their permissions within their own settings, or use a shared set of permissions called a "Schema". The project type configuration determines where a project will get its set of permissions when it is instantiated.
Built-in Permissions
If a project is set to use built-in permissions, these need to be defined in a project configuration. Once the project is launched, changes to the project configuration will not affect the permissions of that project since a project will make a copy of the permissions when launching. 
Schema Permissions
A project can also use a shared set of permissions, called a schema, instead of storing the permissions locally. Within a schema, the permissions are assigned to individual users, so each user can have a different set of permissions within that schema, which allows projects that use that schema to have different permissions for each user. 
Schema Permissions via Global Groups
Using schemas can save administrators a lot of time saving them from manually adding new users to every project. But in large systems, with several schemas, adding a user to the system could require an administrator to manually add that user to several schemas and to specify the permissions of that user in each of those schemas.
An alternative is to use global groups to assign users to schemas. When you configure a global group, you can specify that each user that is part of that global group should be added to a schema using a pre-defined set of permissions. The set of permissions, in this case, would be a role. Each global group can add users to one or many schemas. 
Assignment of Task-Level Permissions
Tasks are sent out automatically by the workflow engine when a project moves from one step to another. Each step can contain one or many tasks, each having its own set of permissions. These are set up when building the workflows. Users and guests aren't given task-level permissions directly but are instead assigned to perform a task, which comes with its set of permissions.
Tasks can be assigned to users, guests, or contact groups. Contact groups can contain users or guests. 
Single Sign-On (SSO) and Permissions
When using SSO, the group membership information can be passed from the authenticating system (like Active Directory or LDAP) to Aproove, which will then automatically look up the names of the groups from the SSO provider and add the user to the global groups and contact groups in Aproove with the same name. This approach allows administrators to grant system-level and project-level permissions, as well as add users to contact groups that assign tasks, by adding users to the correct groups in the authenticating system. Once Aproove is configured with this approach, new users can be granted all the access and tasks that are needed without having to do anything in Aproove.
