Inherited Record Permission Rule – A Workaround by Archer Scripts

Summary

Adding rules to inherited record permission fields has been a wish list item for many people for many years. If you do a simple search on the Archer community, you’ll see people have been asking this question since the early versions of Archer. Unfortunately, the answer is always no because no such features exist. This article shows some cool tricks on how to implement “rules” to inherited record permission fields. Note, this is not a perfect solution, but it should help some organizations in many use case scenarios.

The issues

Inherited record permission is widely used in Archer, but unlike Manual type of record permission and Automatic record permission, we cannot add rules to it. This limitation creates many issues. 

For example, let’s say you have a Department application, in this application, there is a manual record permission field “Department Employees” where all users (or groups) in this department are selected. You are referencing this Department application in your Findings application, and you want to inherit the Department Employees field to allow the users in that field to see their department’s findings. Pretty common use case right? The issue is, suppose you have a requirement to automatically remove Department Employees’ access when the finding record is set to “Archived” or “Inactive”; or to downgrade them from edit to read when the finding is closed, it is not possible as we cannot insert a rule into inherited record permission field to accomplish this requirement. 

In the case of completely removing the permission, one bad solution (but might be the only one out there now) is to create a feed to delink the referenced Department. This is not good because you are changing data and altering history.

If it’s to downgrade from edit to read, usually DDEs are used, to lock all the sections down to read-only. This is not good because first, DDE is not a secure way, users can still edit fields through inline edit or bulk updates (if these options are available). Second, using DDEs to set read-only can get very complicated when you have other 200 existing DDE rules. For example, you have rules that hide fields from sections. Making a section read-only will show all the hidden fields which might not apply to the record and confuse your users. 

 Our workaround

This workaround works well in some use cases. One good example is inheriting Department level access from the “Department” cross-referenced field. Suppose the requirement is when a Finding status is set to Archived, you want to remove access from the inherited permission. The inherited permission is from a field named “Department Level Access” where a department-specific group is selected.

To achieve this, you will need to create 3 helper fields.

Helper – Access Switch

This calculated text field serves as your rule or your switch. It turns on and off based on the condition, in the example above, to check if status = Archived. If so, pull the department name (or anything that can uniquely identify the department) from the “Department” cross referenced field. If the status is not Archived, write a “Not Archived” value. 

Helper – Department Calc

This is a calculated cross-referenced field. The filter is field “Department Name” (from Department) value matches/contains the helper field above,  “Helper – Access Switch”.

So that means when status = Archived, field “Helper – Access Switch” will calculate to be “Department Name”, hence this “Helper – Department Calc” calculated cross-referenced field will calculate to match the same department selected in the “Department” field. On the other hand, if the status is not Archived, this field will be blank.

Helper – Department Access

Now you can probably already tell how it works, this field will be a restricted inherited record permission field. Note “restricted” is key here. You want to inherit the permission from only the helper field above, “Helper – Department Calc”.  When it’s calculated to be the same as what’s selected in “Department”, which means status isn’t archived, it pulls the “Department Level Access” field from the related department record. 

When the status is archived, “Helper – Department Calc” will be blank, and this restricted inherited record permission field will also be blank. Hence, the access is successfully removed dynamically.

The good part of this approach is, your original Department linked to the record is still there, so you are not changing data/history, hence data integrity is not compromised. 

Apply to other scenarios

Now you see how this works, you can apply the same concept for all other scenarios. For example, you could achieve access downgrade (from edit to read) through 2 separate fields. In the example above, you can have two permission fields on the Department level. One for Department Edit Access, one for Department Read Access, and enter the edit/read groups respectively.  Then you need to create your helper fields accordingly to get either the Edit or Read access.

Many companies use Contacts reference in many applications. And in Contacts there are 2 permission fields, one is User Edit access, the other is User Read access, with the actual user selected. So these permissions can be passed down to any applications where the Contacts app is referenced. The approach can work well for this scenario as well (assuming no performance issues). 

Scenarios that might not work too well

This approach works very well to turn on and off permissions. It does work for permission downgrade as mentioned above. However, it might not be too easy to set up in some cases. Note the reason it works in the two scenarios mentioned above is that these two examples involve pretty static permission fields such as Department access groups, or Contacts permission user fields. They can be populated once and will never change.  So you can create both Edit and Read fields and switch between them.  But what if it’s something like “Department Head” that could change? Suppose it’s an Edit field, then you would need to maintain an additional Read field. Here a data feed might be needed to populate the read field automatically whenever the Department Head field is changed. Then you can switch between the two fields.

Caveat

If you decide to use this approach, please test to see if there are any negative impacts to the performance of your application as introducing too many calculated fields might impact performance in some applications (Findings as a good example) where too many calculations are created. Also it might depend on the referenced application. Contacts, for example, might have too many records to be calculated efficiently. This may or may not apply depending on your system resource / data.