Roles & Access Control Lists

In Servis.ai, you can't talk about Access Control Lists without talking about Roles. They work together and you need to understand both to use them properly. That's why we've put both in one article.

What Are Access Control Lists?

ACLs are what define the access within each role. You’re assigning ACLs to each role you’ve created. Except for Admins, they have access to everything.

With Servis.ai Access Control List (ACLs) you have the option to limit the access your team members have in your Apps, based on their Roles, in two different levels:

• Field - Limits write or read access to a specific field.
• Record - Limits create, delete, update, or read access to the records.

You can use conditions to further specify when a role should have limited access to those operations.

User Permissions: Only Administrators can use this feature.

Navigating to ACLs

Navigate to Admin Settings > Company > Roles. Select and edit the specific role for which you want to apply the ACLs. Under the 'Apps' tab, locate the desired app and click the 'Advanced' button. Click on the pencil icon to modify the ACLs for that app. Please note, ACLs are configured on a per-app basis to ensure precise control over access permissions.

What's the difference between Roles and Access Control Lists?

Here's a simple definition of each:

Roles: These are titles you can give to your users that define what actions they can take in Servis.ai.

Access Control List: These can be applied to Roles and define the access each Role has within Servis.ai. This access can be different on a per-app basis.

Create a new ACL

To get started, click the "Add Access Control List" button. 

Here is a list of the information needed to create an ACL:

Next, if needed, you can create Conditions. These are especially useful when you expect the ACL to work only when certain circumstances occur. 

Conditions

Note: Conditions can only be created for Records. 

You can define conditions for Access Control Lists to tailor access permissions precisely. These conditions are inclusive, meaning all specified rules must be met for the ACL to take effect. To create conditions, select 'Records' from the 'Type' dropdown, and then click '+ Add Filter By' to configure your custom rule set.

The operators will vary according to the type of field selected. Here is the list of those available:

For a full list and guide with Operators and Filters take a look at Filter, Sort & More.

Special Considerations

There are some things to keep in mind when creating ACLs. 

• Only the selected roles will be able to perform the selected operation. If the role is not part of the list, they won't be able to perform it.
• Conditions shouldn't be added when the ACL Type is Record and the operation is 'Create'. Since the record doesn't exist yet, there is no information available to match the fields used in the conditions.
• Once you create an ACL of Type Record for any operation, it is required that you create ACLs for the other operations. If you only add one for 'Create', the other operations are not going to be available for any team member. 

Handling Access of Sensitive Record Information

Establishing an ACL is a great way to limit access to certain sensitive information within a record while still allowing other team members to work with that record.  This will function at the Field level, so each Field that contains sensitive information will require its own ACL.

Create an ACL, and choose the Field you wish to restrict access to.  As a reminder, 'Read-Only' and 'Hidden' are the two Field Operations available for the 'Field' Type. 

When creating or editing an ACL, you can select multiple Fields instead of being limited to just one. This allows for greater flexibility and efficiency in defining permissions at the field level, making it easier to manage complex access requirements.

Enforcing Team & Ownership-Based Restrictions

Within the Edit ACL screen, you’ll find two options to enforce restrictions based on Team Membership or Ownership:

•Enforce User is Not in Team: When this option is checked, the ACL restriction will apply to users who are not part of the Users on the Role's specified Team.

•Enforce User is Not the Owner: Selecting this option ensures that ACL restrictions apply to all users who are not the Owner of the Record.

These features provide added flexibility for fine-tuning access control and ensuring permissions align with your organizational structure.

How does this works? Here are a couple examples

In Servis.ai, Access Control Lists (ACLs) give you the flexibility to control who can see or modify specific fields based on Ownership or Team Membership. Here’s how you can use ACLs to restrict access to Fields in the 'Contacts' app.

Scenario 1: Restricting Access Based on Ownership

Imagine you’re an administrator, and you want to ensure that only the Owner of a Contact Record can fully access specific Fields in the 'Contacts' app:

• The 'Account' Field should be 'Read-Only' (non-editable) for everyone except the Owner.
• The 'Contact Stage' Field should be completely 'Hidden' (blank) from users who are not the Record Owner.

Here’s how to set this up:

Step 1: Restrict the 'Account' Field

• Go to ACLs and click 'Add Access Control List'.
• Select 'Field' Type.
• Choose 'Account' as the Field you want to restrict.
• Set the Field Operation to 'Read-Only'.
• Check the box labeled 'Enforce User is not Owner' to apply the restriction to Non-Owners.
• Click Save to confirm.

Step 2: Restrict the 'Contact Stage' Field

• Click 'Add Access Control List' again to create another ACL.
• Select 'Field' Type.
• Choose 'Contact Stage' as the field to restrict.
• Set the Field Operation to 'Hidden'.
• Check the box labeled 'Enforce User is not Owner' to apply the restriction to Non-Owners.
• Click Save to confirm.

Step 3: Save the Role Settings

• After creating the ACLs, close the ACL window to return to the Role's Settings page.
• Click the Save button at the bottom of the page to apply all changes.

Result:

• The 'Account' Field will be 'Read-Only' (non-editable) for users who are not the Owner of the Contact Record.
• The 'Contact Stage' Field will be 'Hidden' (blank) for users who are not the Owner of the contact record.

If someone without the required permissions tries to check these fields:

•The 'Contact Stage' Field will appear blank.

•The 'Account' Field will be visible but unmodifiable.

Scenario 2: Restricting Access Based on Team Membership

Now, let’s say you want to apply the same restrictions, but instead of Ownership, you want to control access based on whether a user belongs to the Team managing the Contact Record:

•The 'Account' Field should be 'Read-Only' (non-editable) for users not part of the Team.

•The 'Contact Stage' Field should be 'Hidden' (blank) from users not part of the Team.

Here’s how to set this up:

Step 1: Restrict the 'Account' Field

• Go to ACLs and click 'Add Access Control List'.
• Select 'Field' Type.
• Choose 'Account' as the field you want to restrict.
• Set the Field Operation to 'Read-Only'.
• Check the box labeled 'Enforce User is not in Team' to apply the restriction to non-Team members.
• Click Save to confirm.

Step 2: Restrict the 'Contact Stage' Field

• Click 'Add Access Control List' again to create another ACL.
• Select 'Field' Type.
• Choose 'Contact Stage' as the field to restrict.
• Set the Field Operation to 'Hidden'.
• Check the box labeled 'Enforce User is not in Team' to apply the restriction to non-Team members.
• Click Save to confirm.

Step 3: Ensure Team Field is Active

• Make sure the Team Field is active and properly assigned to Contact (Form Fields) Records. This is crucial for the ACLs to recognize a user’s Team membership and apply the restrictions correctly.

Step 4: Save the Role Settings

• After creating the ACLs, close the ACL window to return to the Role’s Settings page.
• Click the Save button at the bottom of the page to apply all changes.

Result:

•The 'Account' Field will be 'Read-Only' (non-editable) for users who are not part of the Team managing the Contact Record.

•The 'Contact Stage' Field will be 'Hidden' (blank) for users who are not part of the Team.

If someone outside the Team tries to access these fields:

•The 'Contact Stage' Field will appear blank.

•The 'Account' Field will be visible but unmodifiable.

By setting up these ACLs, you can ensure sensitive Fields in the 'Contacts' app are accessible only to the appropriate Users, whether based on Ownership or Team Membership. This gives you granular control to meet your organization’s access requirements in a secure and efficient way.

Editing an ACL

Existing ACLs can be edited in case you want to change them. To do this, simply click the 'Edit' button. 

Here you will be able to change everything, from the Type and Conditions (only for Records Type) and change the actions they will be able to perform. Just make your changes and click the 'Save' button when you are done.

Adding Users to an ACL

Adding users to each of the Roles for your company is quite simple. First, navigate to Settings > Company > Roles. Then choose a Role and select 'Edit'.

Click on the 'Users' field to get the dropdown list with your available Users to choose from. You can assign multiple users to a Role.

Search ACLs

To find a specific ACL, you can use the search box available at the top of the page. You can also use the advanced search to narrow them down and display only those you need. To learn more about the advanced search, please visit the 'Advanced Search' section of the following tutorial:
Global Search

Duplicating Roles and ACLs

Servis.ai provides a quick and efficient way to duplicate Roles and ACLs, saving you time when setting up similar permissions or configurations for your team. Here’s how you can duplicate them:

Duplicating Roles

To duplicate an existing Role:

• Navigate to Settings > Company > Roles.
• Click on the three dots next to the Role you want to duplicate.
• Select 'Duplicate' from the dropdown menu.

When duplicating a Role:

• All associated members of the original Role will be retained in the duplicate.
• It’s recommended to rename the duplicated Role or update its description to avoid confusion.

Duplicating ACLs

To duplicate an ACL:

• Navigate to Settings > Company > Roles.
• Select and edit the specific Role for which you want to duplicate an ACL.
• Under the 'Apps' tab, locate the desired app and click the 'Advanced' button.
• Click on the pencil icon to access the ACL editor for the app.
• Click on the three dots next to the ACL you want to duplicate.
• Select 'Duplicate' from the dropdown menu.

When duplicating an ACL:

•All configurations will be copied, including Conditions, Fields, Checkboxes, and Operators.

•You can then adjust the duplicated ACL as needed to fit your requirements.

By using the duplication feature, you can easily replicate Roles and ACLs while maintaining consistent settings across your team, streamlining your administrative workflow and saving valuable time.

Deleting an ACL 

If you created an ACL for a really specific purpose but eventually decide that you don't need it anymore, you can always delete it. Click on the three dots next to the role and select 'Delete'. If you try to delete a 'Role' that has users assigned, you will receive an error message, as it is required that you remove the users from the role before deleting it. 

Edit the 'Role' to remove any active user and click the 'Save' button before attempting to delete the Role. Once you do the role will no longer be active and will not appear on the list.

Access Control Lists (ACLs) are a powerful tool in Servis.ai that enable you to define precise access permissions for your team, tailored to their roles and responsibilities. By understanding how ACLs interact with Roles, you can create a secure and efficient workflow, ensuring that team members have access only to what they need.

Remember, only Administrators have access to create, edit, and manage ACLs.