Skip to main content

User Access

Overview​

Incentify provides the following hierarchical layers of user access and permission logic:

  • Account Level Access
    • User Permission Groups
      • Access Policies
        • Entity Access

Account Level Access​

Single Account

A User is granted access to an Account via the User - Create/Update endpoint, which requires a speciifc User Permission Group be assigned (see below).

Parent / Child Account

If a User is granted access to a Parent Account via the User - Create/Update endpoint, which requires a speciifc User Permission Group be assigned (see below), then that user has access to that Account and all Child Accounts (and their data) underneath it.

If a User is granted access to a Child Account via the User - Create/Update endpoint, which requires a speciifc User Permission Group be assigned (see below), then that user has access to that Child Account (and the data within it).

User Permission Groups​

User Permission Groups define what actions a User can and can not do within an Account, such as Create a Project, Delete a Credit or Manage Users. There are two types of User Permission Groups: (1) Internal and (2) External.

Internal User Permission Group

A white list of domains is configured for your account, which correlates with your company's one/more domains. Any user matching that domain is permitted to be assigned to an Internal User Permission Group. These groups are fully customizable and all Actions can be selected/unselected.

External User Permission Group

Any email address that is NOT on the white list of domains configured for your account are permitted to be assigned to an External User Permission Group. These groups are fixed in terms of Actions configured (ie; they are limited and their permissions are managed by Incentify).

Users are assigned to User Permission Groups via the User - Create/Update endpoint.

Access Policies​

An Access Policy is a baseline access configuration for major objects in the system that apply broadly to cohorts of user types.

There are four possible Access Policies:

  • exclusive: only the User who created the object can view/access the object (as well as any Entity Access records - see below)
  • private: only (i) the User who created the object, (ii) the Account Admin and (iii) all Parent Users can view/access the object (as well as any Entity Access records - see below)
  • all_internal: only (i) all Users of Internal User Permission Groups, (ii) the Account Admin and (iii) all Parent Users can view/access the object (as well as any Entity Access records - see below)
  • all_users: all Users can view/access the object

The following Objects in Incentify have Access Policies with three possible policies available (private, all_internal, all_users):

  • Projects (which contain Credits and Utilizations)
  • Workflow Templates
  • Compliance Templates
  • Sites
  • Legal Entities

The following Objects in Incentify have Access Policies with four possible policies available (exclusive, private, all_internal, all_users):

  • Documents

Access Policies are configured by creating/updating the object. For example, see the Project - Create/Update endpoint to understand how to set an Access Policy.

Entity Access​

General Concept

All Objects that have Access Policies also have Entity Access configurations. While Access Policies are broad rules for cohorts of users, Entity Access is specific user-to-object configurations. Entity Access permits "access" to an Object and it provides two types of "access":

  1. access: User has access to the Object, but can only take Action on that Object based on that User's Permission Group. For example, if a Project has a private Access Policy created by User ID 123 then User ID 456 will not be able to view/access that Project. However, If User ID 456 is granted Entity Acess to that Project, then User ID 456 will now be able to take view/access that Project as well as take Action on that project based on the User Permission Group rules that User ID 456 is part of.
  2. read_only: This behaves the same way as access above, however, User ID 456's will NOT be able to perform any Actions that the User Permission Group rules allow for that User ID 456 is part of (ie; locked to "Read Only" level access).

Project, Credit and Utilization Access Hierarchy

The only complicated logic for Entity Access is the fact that Utilizations are part of Credits and Credits are part of Projects - which means hierarchical permissions take effect. In this hierarchy, Entity Access can be set at either the Project Level or the Credit Level.

Therefore, there are two potential scenarios here:

  1. A User has Entity Access (or indirect access via the Access Policy) and is able to view/acess the Project, its Credits and its Utilizations - and take Action upon those objects based on the User Permission Group rules that the User is part of.
  2. A User does NOT have Entity Access (or indirect access via the Access Policy) to a Project - but DOES have Entity Access to one (or more) of its Credits. In this scenario, the User only has access to the Credit(s) (and their Utilizations) configured, and has "read only" level access to the Project.

Entity Access is configured by creating/updating the object. For example, see the Project - Create/Update endpoint to understand how to set Entity Access.