Introduction to permissions

This section details the granular level of access control that an administrator (admin) can apply via profiles to permissions, across the entire suite of Apteco software.

Note: Installation of Orbit is required to administrate and use permissions.

Permissions for users, groups, and systems

Using Permissions, system admins can grant or restrict access for the following profiles:

  • Users

  • Groups

  • Systems

Permissions allow an admin to control which parts of an Apteco software installation a given profile can access, limiting interaction with the features and functionality specified by the admin.

For a new system, the default system level permissions allow an admin access to all resources. Post installation system permissions should be adjusted to reflect your organisations security requirements.

Permission states

A permission can be in one of three states:

  • Granted (a tick): A granted permission resource is visble to a profile.

    Denied (a cross): A denied permission resource is hidden, and not visible to a profile.

  • Undefined (empty): An undefined permission denies access to a resource if no overriding permission exists.

Permissions for multiple groups

Note: Permissions are inherited. A user receives all permissions that are assigned to their user, group and system profile.

Multiple groups are used to conveniently apply multiple permissions to a user. Having multiple groups only makes a difference when users & groups/permissions features are used together.

You can place a user in multiple groups if you’re not using user permissions. However, only the starred group is recognised by FastStats.

Some general guidelines on permissions assignment are:

  • Users should be assigned to one or more groups

  • Groups should represent a function of the end user, perhaps a country, region, or product

  • Permissions should be assigned to groups as standard, making resolution of security issues easier to understand

  • Permissions should only be assigned to users as an exception

Permission resources

The underlying structure behind permissions is that users, groups, or systems have access to a resource.

  • A resource is a feature that exists in either PeopleStage, FastStats, or Orbit. Resources include Areas, Campaigns, Files, Templates, Voucher Seeds, Communication Channels, Roles, etc.

  • Access to different types of resources are denied or granted through permissions. There are different types of permissions.

Resources are further broken down into two broad categories, hierarchical and tagged:

  • A hierarchical resource is the child or parent of another resource of the same type

  • File directories, campaigns, and areas are examples of hierarchical resources

  • A tagged resource does not have parent or children, templates, voucher seed sets, Velocity restrictions or export channels are examples of tagged resources

  • Tags are used to group resources together

Permission resource types

Once users, groups, and resources are created, there are two workflows for assigning permissions:

For Tagged Resources:

  1. Create a tag (if it doesn’t already exist).

  2. Link a tag to a resource.

  3. Apply permissions to the linked tag for that resource type in the Permissions UI.

For Hierarchical Resources, apply permissions to the resource in the Permissions UI.