There are two configurable layers of security in Lanetix:
(1) Standard Security which applies to entire record types
(2) Enterprise Security which can reduce access to records within a record type based on other system information - Please work with your Lanetix account manager to configure this feature for Enterprise account plans.
Standard Security is required for all records and workflows, and this is the basic way to grant Create, Search, Read, Update and Admin access. As an admin, go to the Users and Groups tile in Studio, then to the Group Menu item select a group name from the left menu.
Add all records that the group can access by clicking the Add or Remove Record Templates button. Similarly, click the Workflow tab at the top to grant access to Workflows on a record type. Select the checkboxes for each to allow Read, Create, Update, Delete, Search or Admin Access to those records respectively. For workflows, you will be granting Read and Start access.
You will always have to grant access to a record type or workflow. Any new templates that are built will be excluded from access here until they are added by an administrator. This helps to ensure that data is not shared unintentionally with any group.
Access is cumulative for a user across multiple groups. This means that if a user is in a group with a particular permission checked, they will have that permission, regardless of whether the permission is not checked in another group.
Contact your Lanetix account manager to discuss enabling this feature for your Enterprise account plan organization.
With these more fine-grained tools you can limit access to specific records and fields based on conditions, including field values and user ownership.
Note: Changes to Enterprise security Rules and Exceptions are not activated immediately. Clicking the Save button enters your updates into a queue, which may take up to an hour to become active.
If you do need to configure more granular security rules, make sure you have planned out how you expect security rules to work. Your account manager will work with you to complete a planning worksheet prior to configuration. To start with, consider these questions:
- Which record types should be limited?
- Which groups should have limited access?
- What do those limitations entail?
- What exceptions are there to each rule (if any)?
- Can members of other groups read or update this record type?
An common example may be:
- Which record types should be limited? Accounts
- Which groups should have limited access? Sales Group
- What do those limitations entail? Members of the Sales Group can only edit accounts that they own.
- What exceptions are there to the rule? They can read all accounts even if they don’t own them.
- Can members of other groups read or update this record type? Sales Managers can both read and update the records.
If a record type is limited for an entire group, consider using only the Standard Security to enact your rule. For example, if users in a group can only Read certain record types, simply give them Read and Search access via the group page. If users of a group cannot view a specific record type at all, simply remove access to that record type via the group page.
To set up Enterprise Security, navigate to the Studio > Users and Groups > Groups and create a group containing all of the members of the Sales Team that this rule applies to.
Based on the answer to #5 in our above example, Sales Managers can read/update these records. Therefore, you will also need to create a Sales Managers Group and add all appropriate members. Note: Rules must target Groups of users, and not individual users.
Once the groups are prepared, go back to Studio > Record Builder> Record Type, in this case Account and click on the security tile in the lower right hand corner.
You will see a default “Everyone” rule, click the three ellipses to Delete this rule.
Next, click the New Rule button. In the slide out, name and describe the rule.
Click the checkboxes to allow Update or Delete access (note that Read is already defaulted “on”). Add the “All Sales” Group, then add parameters in the same way you would build an Insight. In this case, we are adding the filter Account Owner ID is Current User.
Save the Rule. You have now accounted for items #1 - #3 of the documentation.
Adding a Second Rule
Repeat the process to create a rule allowing Sales Manager Users to Read and Update the records. In this case, your parameter will be Deleted is false and will account for documentation point #5.
If a user is included in more than one security group, and those groups are all active on different rules of a record, only one rule will apply. The security rules are adhered to from the top down. Therefore if the user is included in the first rule, at the top of the list, and one further down in the list, only the top rule will apply. In the example below, a Sales Manager that is also in the Sales Group would not be able to update records since the first rule gives that user Read-Only rights.
For this reason, it is best that each user is only present in a single group, since it can become complex when you have differing rules over differing record types. Or, if you prefer to have them in two groups, ensure that the presiding rule for that user is listed first in the Rule Hierarchy.
Exceptions allow READ-ONLY access that overrules an existing security Rule. In this case, we want to allow Sales Users to read all accounts despite ownership, which was limited on the Security Rule. Click the Create Exception button. In the slide out, name and describe the exception.
Add the Sales Group to the Exception, input the parameter Deleted is false and click Save. This Exception has now accounted for documentation item #4.
Note: If there is not a Security Rule to overrule, Read-Only access can be granted in Standard Security by checking the “Read” and “Search” access buttons only. Remember that Standard Security at the group level is preferred for better performance and easier maintenance.
Blacklisting a field on a rule allows you to lock the field against reading or editing for that group of users. Add blacklisted fields to the rule or exception to prevent users covered by those rules from seeing or updating them.
You can blacklist a field on the rule, but then create an exception (since you are overruling the security rule) for the same group to allow read only access for that field.
Tips and Best Practice Suggestions
- Use Standard Security wherever possible and leave the default Everyone rule intact.
- Document the expected outcome of each rule before configuring.
- Plan Enterprise Security configuration with your Lanetix Account Manager
- Only add User Groups to Security Rules and Exceptions, not individuals.
- Every Rule and Exception will need at least one parameter. The simplest is Deleted is false.
- For audit purposes, it best to set up the Standard Security to reflect the Enterprise Security configuration. ie. If a group has read and update access on the enterprise configuration, set them up with the read and update access, as well as create and search if desired, on the Standard level.