Permissions

Atomic gives fine grained control of the permissions assigned to team members, so you can configure them to match your organization’s roles.

Permissions overview

Workbench team members can be assigned to one or more groups. Each group has access to roles. Each Role gives access to specific resources. We’ll cover what each of these different levels of access are in detail below, so you can configure your account to best suit your organization.

By default a new Atomic organization comes with three roles (Owner, Admin, and Editor), each with default permission levels outlined in the Permissions for default roles table.

Resource

There are many different resource types in the Atomic Workbench which Workbench members can interact with.

Each resource type has up to three permissions, which specify the actions that can be taken by the member for that resource:

1. View
2. Edit
3. Admin

Some resources only offer a limited set of actions, for example 'Activity log' can only be viewed.

See the Permissions resources section for a description of each different resource and the access available.

Role

A role is a collection of one or more permissions. For example, a custom role called "Card editor" could have the permission to edit the card templates resource as well as the permission to view the theme resource.

Create a role

1. In the Workbench Members area, select the ‘Role’ tab, select ‘Create new role’
2. Give the new role a name and description
3. Select each resources and its corresponding permission level
4. Select ‘Create role’

Update a role

1. Select the role from the Workbench Members area.
2. Make the required changes (add or remove permissions to a resource, and/or add additional resources)
3. Click Update role button in top right corner.
4. Refresh the page when you're making changes to permissions for your own logged in workbench user for the changes to take effect.

Groups

A group is a collection of roles, based on particular job functions. Groups can be scoped to all or only specific environments. By default a group is assigned the role for all environments in the organization. For example, a “Card creator” role and a “Theme viewer” role.

Create a new group:

1. In the Workbench Members area, select the ‘Groups’ tab, then ‘Create new group’
2. Give the new group a name and description
3. Select the Role(s) the group will have access to
4. (optional) Select the specific environments. See the comment below about resources being scoped to the environment or organization level.
5. Select ‘Create group’

Resources are scoped to the environment or the organization level

Some permissions can not be limited to an environment level, because their corresponding resource has an organization-wide scope.
Read more in the Scoping of resources section to understand what this means for your setup.

Configure permissions for your team

Team members

Workbench members can be given memberships to one or more groups. Based on those groups they’ll be granted permission to access the specified resources and environments.

workbench user group assignment permission required

Only workbench members with permissions to the ‘Workbench user group assignment’ resource can add or remove workbench members from groups.

Invite a new workbench member

1. Click the 'manage' button in the bottom left corner and select Workbench members.
2. Click ‘invite new member’.
3. Add their first and last name, email address, then select the Group(s) they will have access to.
4. Select ‘Invite’ to send them an invite via email.

Disable a workbench member

1. Click your avatar in the bottom left corner > Workbench members
2. Select the overflow menu for the team member you wish to disable, and select ‘Disable’.

Scoping of resources

Some resources can be limited to one or more environments, other resources have permissions that are set on an organization level. The list of permissions that can only be applied to the whole organization are listed in the Organization-scoped workbench resources section of the Permissions resources guide.

To limit access of permissions to certain environments only, you need to explicitly select the environment names the group does have access to. If no environment has been selected, the group has access to all environments.

Any groups that are limited to specific environments will not have access to any of the resources that are controlled by organization-level permissions. To grant workbench members access to an organization-level resource, make them part of a role and a group that has explicit access to (one or more of these) organization-level permissions, ensure the group is scoped to allow access to all environments.

Example of an environment and organization scoped permission group

A group "analysts" needs:

• access to the analytics exporter for 1 (test) environment
• access to the audit log (an organization level resource)

The way to achieve this, is by creating 2 roles and assigning them to 2 groups. It's good practice to use the same name for a role and its corresponding group.

• the "analytics - test" role has view permission to the analytics exporter resource. The "analytics - test" group is scoped to only allow access to the "test" environment within the organization
• the "audit log" role has access to the audit log and the "audit log" group has access to all environments

Scoping to Action Flow folder

Preview feature

Folder-scoped access is in preview and may be subject to change. Please contact us to provide feedback.

When a group's Action Flow permission is scoped to a specific environment, you can optionally restrict that group's access to one or more top-level folders. Members of the group will only be able to see and edit Action Flows filed within those folders (and any sub-folders beneath them).

To configure folder access for a group:

1. In the Workbench Members area, open the group you want to configure.
2. Review the "Scopes" section on the relevant role(s) assigned to the group.
3. In the Folder access section, select the top-level folders the group should have access to.
4. Click Save.

Leaving the folder access section to "All folders" grants unrestricted access to all Action Flows in that environment. If you change the toggle to "Selected folders" but do not choose any folders then users will not have access to see or edit any Action Flows and associated resources.

How access combines across groups

A member's access is the union of all their groups' grants:

• If any of their groups has unrestricted access to an environment, folder restrictions from other groups are ignored for that environment.
• Groups scoped to all environments cannot have folder restrictions, so members of such a group are unrestricted everywhere.
• If all of a member's groups for an environment are folder-restricted, they can access the combined set of those folders (and their sub-folders).

What restricted users see

On the Action Flows list page:

• The folder panel shows only the folders they have access to. A padlock icon appears when access is limited to specific folders.
• The Uncategorized filter is not shown, since restricted users cannot access unfiled Action Flows.
• The engagement stats panel at the top of the page is automatically filtered to the accessible folders.
• Sub-folders can still be created inside accessible folders, but new top-level folders cannot be created.
• The top-level restricted folder cannot be deleted or renamed.
• When a sub-folder is deleted, any Action Flows inside it are moved to the top-level folder.

On the Insights dashboard:

• The Folders filter is pre-populated with the accessible folders, and tiles show data scoped to Action Flows in those folders (and any sub-folders).
• The folder picker lists only accessible folders, and the filter can be narrowed but not cleared.
• The saved reports list only shows reports whose folder filters fall within the accessible folders. Reports saved without any folder filter are hidden, and saved reports cannot be created or updated to filter on folders outside the accessible set.

Permissions resources

This document contains a list of each unique resource type, with a description of each, and the permissions available for that resource.

Each resource type has up to three permissions available, which specify the actions that can be taken by the member for that resource. The acronym CRUD in the table below stands for Create, Read, Update and Delete permissions. Edit permissions include view permissions, and admin permissions include edit permissions.

Workbench resources

Resource	Description	View Permission	Edit Permission	Admin Permission
Action Flow	View, create, edit, and delete Action Flows. Access can optionally be scoped to specific folders.	View and browse Action Flows	Create, edit, and delete Action Flows	n/a
API authentication controls	Used to authenticate your requests to the Atomic API	List credentials	CRUD	n/a
Analytics exporter	Access to view analytics and download batched analytics sets	Download & view analytics	n/a	n/a
Audit log	Log of workbench members’ actions within your organization (org scoped)	View own audit log entries	n/a	View others' audit log entries
Card instance	An instance of a card template sent to a customer	View log and analytics	Send cards from workbench	Cancel sent cards
Insights	Access to the Insights dashboard and analytics	View the Insights dashboard	n/a	n/a
Card template	Used to view, send, edit and publish card templates	View card templates and media, send test cards	Edit draft card templates and media	Publish and archive card templates
Client certificates	Used to view and update client certificates for mTLS	View and use client certificates	Add, replace, and change client certificates	n/a
Connectors	Configuration for incoming webhook connectors	View	CRUD	n/a
Container	Configures card streams within your app	View	CRUD	n/a
Customer	A user of your web and mobile applications	n/a	n/a	CRUD
Customer Center	Access to the Customer Center	View the Customer Center	Send Action Flows to customers from the Customer Center	n/a
Environment	Each environment within an organization is a separate space, with separate configuration	View environment name	Create and edit name	Deactivate and edit custom fields
Notifications	Push notification configuration details for each SDK platform	View config details	CRUD	n/a
Organization	Atomic customers are typically given one organization. Each organization contains multiple environments (org scoped)	View name and preferences	Edit name and preferences	n/a
Override card approval	Enables a member to approve on behalf of any approval group	n/a	n/a	Approve on behalf of any approval group
Role	An identity with specific permissions. A role can be assigned to 1 or more groups, giving a set of permissions to all members of that group (org scoped)	View all roles and their permissions	Create and edit roles	n/a
SDK API key	Needed for SDK integrations, and to configure allowed JWT issuers	View API key	CRUD	n/a
Segment	Subset of customers with common characteristics	View which filters are applied	Create and edit segments	n/a
Stream	A collection of cards which can be assigned to 1 or more stream containers in your apps	View	CRUD	n/a
Tag	Tags are available when filtering customers	View	CRUD (inc user tags)	n/a
Theme	Theming configuration for stream containers	View	CRUD	n/a
credentials	Authentication credentials for webhook and Action Flow send-request requests	View	CRUD	n/a
Webhook request log	Status and metadata for outgoing webhook requests	View metadata	n/a	n/a
Webhook subscription	Requests made from Atomic to external services	View	CRUD	n/a
Workbench member	A member of the workbench (org scoped)	View	CRUD	n/a
Workbench member group	Controls workbench member groups and their associated roles (org scoped)	View	CRUD	n/a
Workbench member group assignment	Controls assignment of workbench members to groups (org scoped)	View	CRUD	n/a

Example permission sets

Card approval

People who only need to approve cards can be given a view permission on the card template resource - no other permissions are needed.

Insights dashboard

People who need access to the Insights dashboard need view permissions on the Insights resource.

Organization-scoped workbench resources

Some resources are scoped to the organization level as opposed to the environment level. This means that permissions to these resources can't be limited to an environment.

These resources are:

• audit log
• organization
• request debugger
• role
• workbench member
• workbench member group
• workbench member group assignment

See the Scoping of resources section for a further explanation and a worked example of how to create a group with environment-level scoped resource permissions as well as organization-level scoped resource permissions.

Permissions for default roles

By default your Atomic account comes with three groups: Owner, Admin, and Editor.

This table describes the default permissions each of these roles has:

Resource	Owner	Admin	Editor
API authentication controls	Edit	Edit
Analytics exporter	View	View
Card instance	Edit	Edit	View
Insights	View	View
Card template	Admin	Admin	Admin
Client certificates	Edit	Edit	View
Container	Edit	Edit	View
Customer	Admin	Admin
Environment	Admin	Admin	View
Notifications	Edit	Edit
Organization	Edit	Edit	View
Override card approval	Admin	Admin	n/a
Request debugger	Edit	Edit
Role	Edit	Edit
SDK API key	Edit	Edit
Segment	Edit	Edit
Stream	Edit	Edit	View
Tag	Edit	Edit	View
Theme	Edit	Edit
Credential	Edit	Edit
Webhook request log	View	View
Webhook subscription	Edit	Edit
Workbench member	Edit	Edit
Workbench member group	Edit	Edit
Workbench member group assignment	Edit	Edit