Roles and permissions
Formsort accounts are organized according to roles and permissions, in order to maintain the integrity of your form flows across team members, as well as to clearly delineate responsibilities across the team.
Examples of roles include, for example, Owner, Administrator, Deployer, Designer, and Engineer. Roles are associated to specific permissions such as Archive or delete flows, or Create or update themes. By assigning team members' accounts to different roles, you can control exactly which actions in the platform are available to whom.
The current list of permissions is as follows:
These permissions are associated to the following roles:
create_new_variant revision
✓
✓
✓
✓
✓
✓
update_environment
✓
✓
✓
update_domain
✓
✓
✓
update_credential
✓
✓
✓
update_theme
✓
✓
✓
switch_theme
✓
✓
✓
deploy_production
✓
✓
✓
update_traffic_pattern
✓
✓
✓
delete_flow
✓
✓
delete_variant
✓
✓
view_accounts
✓
✓
billing_access
✓
✓
suspend_account
✓
An Admin cannot assign or create an Owner role. Please make sure to re-assign the Owner permissions if the account is going to be suspended. If you find that there are no Owner-level permissions for your account, please reach out to the Formsort team via Intercom.
Role Organization
Roles are organized according to a hierarchy, visualized in the diagram below. At the top-level of the hierarchy is the Owner, meaning that the Owner has access to all permissions associated with all roles under it. Moving down the hierarchy, we have the Admin: the admin has access to all permissions except permissions specific to Owner, such as the ability to Suspend other accounts. The same rule applies at any level of the hierarchy: a given role has a subset of the permissions of the roles higher on the hierarchy, a superset of the permissions of the roles lower.
Adding roles and permissions
A given permission can only be granted by a user who already has that specific permission. In other words, a Deployer can grant another user with Deployer permissions, a Designer with Designer permissions, and an Engineer with Engineer permissions. However, a Deployer cannot assign a user with e.g. Engineer or Admin permissions.
We have not yet implemented functionality to provide visual cues or to hide features which a user does not have permission to use. Currently, any feature that a user does not have permission for will appear normal in the platform, but the user will not be able to use it.
Managing response access with user groups and access policies
Formsort allows you to control who can access response data using user groups and access policies.
User groups
User groups let you grant response access to multiple users at once. Instead of manually managing access for individual users, you can create a group and apply it to one or multiple forms.
User groups are managed in the Admin Workspace settings.
Any user added to a group with response access will automatically have read, tag, and download permissions for the assigned forms.
Access policies
You can create an access policy at both the form level and in the Admin Workspace settings.
To create an access policy, you must define:
A user or user group that the policy applies to.
The resource (form) that the policy applies to.
Since all users with response access can read, tag, and download responses, access policies simply determine who can access responses for each form.
Last updated
Was this helpful?
