You can access your preferences by clicking your avatar in the top right corner.
Manage your name, email, and phone number.
Edit the name of your organization.
Data retention (beta)
Set the number of days of data to retain for:
- Audit logs
- Analytic batches & events
- Completed Action Cards and Action Flows
- SDK request debugger logs
- Webhook logs
Note: Purging this data has no impact on the insights dashboard.
Make Multi-Factor Authentication (MFA) required for your Workbench members.
Change the inactivity period after which workbench members will be logged out, this period is expressed in minutes and defaults to 30 minutes.
Show all JWT claims in SDK request debugger
Enabling this setting will log all JWT claims in a given SDK request in the request debugger tool. Depending on the content in the JWT this may include sensitive information.
Manage your environments, including adding new environments.
Invite a team member
Note: only Workbench members with edit permissions to the ‘Workbench user group assignment’ resource can manage members.
Click on your avatar (top right), and select ‘Workbench members’, then ’Invite new member’. Enter the person's first and last name, email address, and the group(s) you'd like them to belong to.
Single sign-on (SSO)
Atomic supports Workbench members logging in using either an email and password, or Single sign-on (SSO). When using SSO authentication, it is also possible to manage authorisation by your identity provider. Contact us with the name of your identity provider, and we’ll provide you the configuration instructions.
Revoke an invite
Note: only Workbench members with the ‘Workbench user group assignment’ resource can manage members.
Navigate to the ‘settings’ tab, and select ‘team members’, and ‘invites’. Select the menu on the right, then ‘cancel’.
Atomic gives fine grained control of the permissions assigned to team members, so you can configure them to match your organization’s roles.
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.
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:
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.
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
- In the Workbench Members area, select the ‘Role’ tab, select ‘Create new role’
- Give the new role a name and description
- Select each resources and its corresponding permission level
- Select ‘Create role’
Update a role
- Select the role from the Workbench Members area.
- Make the required changes (add or remove permissions to a resource, and/or add additional resources)
Update rolebutton in top right corner.
- Refresh the page when you're making changes to permissions for your own logged in workbench user for the changes to take effect.
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:
- In the Workbench Members area, select the ‘Groups’ tab, then ‘Create new group’
- Give the new group a name and description
- Select the Role(s) the group will have access to
- (optional) Select the specific environments. See the comment below about resources being scoped to the environment or organisation level.
- Select ‘Create group’
Some permissions can not be limited to an environment level, because their corresponding resource has an organisation-wide scope.
Read more in the Scoping of resources section to understand what this means for your setup.
Configure permissions for your team
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.
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
- Click your avatar in the top right corner and select Workbench members.
- Click ‘invite new member’.
- Add their first and last name, email address, then select the Group(s) they will have access to.
- Select ‘Invite’ to send them an invite via email.
Disable a workbench member
- Click your avatar in the top right corner > Workbench members
- 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