This article looks at how the system assigns privileges to the user when there are conflicting role and page layout privileges. 

Table of Contents

Overview

When working with access restriction, specifically with roles and page layouts, you might end up asking yourself:

• If conflicting privileges for multiple roles assigned to the same business user exist, how does the system determine what privileges to assign?
• How do roles and page layouts work in tandem, especially if there are conflicting privileges from multiple assigned roles?

The section below focuses on answering these question.

Example Scenario

Based on the access rights assigned, the system first determines if the logged in user gets access to the content. For example, role 1 grants "read" access while role 2 grants "edit" access to the same object.

In this first case, if a user is assigned to two business roles, one granting "display-only" access and another granting "edit" access, then preference is given to "edit" access. The user will be given "edit" access to the transaction.

Now, going one level deeper, if only part of the object can be edited, then it can be controlled through the page layouts.

For example, let's say there are two user groups that have "edit" rights to the objects. However, they are only allowed to edit a subset of fields or their combinations. In this case, you can have two roles, both allowing "edit" access, but with two different page layouts with defined combinations of "read-only" fields.

Determining which page layout should get assigned to which role can also be controlled by another field, which is the instance type for a Business Object.

The two tables below represent an example of the two different page layouts setup:

PageLayout 1(VintestRestrictedPL)

Page Layout 2(VintestPLEditRestrictedFacet2)

In our example, if the field VintestRestricted has a value of True, then the page layout VintestRestrictedPL gets assigned to the role of VintestOppCOntrolFacet1, else the master is assigned. The VintestRestrictedPL page layout doesn’t allow the edit of the F1 field. However, the edit of field 2 and 3 are allowed.

Similarly, if the VintestRestricted field has a value of True, then the second page layout VintestPLEditRestrictedFacet2, gets assigned to the VintestOppCOntrolFacet2 role, else the master is assigned. The page layout, VintestPLEditRestrictedFacet2, doesn’t allow the edit of the F2 field. However,  the edit of the F1 field is allowed, and the F3 field is hidden.

Now, let's consider what the behavior will be when the user logs into the system for the following two scenarios:

1. User Tara is assigned to the role VintestOppCOntrolFacet1
2. User Kamala is assigned to the roles VintestOppCOntrolFacet1 and VintestOppCOntrolFacet2 (conflicting roles)

If user Tara logs in, and an Opportunity has the VintestRestricted value set to True, then the VintestRestrictedPL page layout is determined based on Tara's singular access to the role VintestOppCOntrolFacet1.

Therefore, the F1 field should be "read-only" for her, and the F2 and F3 fields should be editable.

When user Kamala logs into the system and accesses the same Opportunity with the restricted value set to True, the behavior is quite different.

The reason for the above is that Kamala has two assigned roles that conflict with each other.

The table below reviews the field behavior from this scenario:

Therefore, we can extrapolate based on this scenario some basic principles:

• Page layouts can be assigned to roles based on an instance type. For example, the restricted fields from the above examples.
• It is also possible to combine conditions to assign a specific page layout. Now, since only one instance type field can be used to control the page layout assignment, you can create an additional custom field which can be updated based on the values of the two fields. This combined field can then be used as the instance type field.
• If a user is assigned to multiple business roles and conflicting privileges exist, in that case: 
  • If the "read-only" or mandatory property is enforced by any of the assigned page layouts of the applicable roles, it prevails. 
  • If the field is made invisible in any of the assigned page layouts of the applicable roles for the logged in user, it is set to "invisible". This holds true for fields, facets, sections groups, basically, wherever you have the visible property exposed.
  • To avoid this conflict, we highly recommended evaluating why someone would assign multiple roles with conflicting privileges.
• If you want to control the behavior for different roles by allowing the possibility of "saving" or "not saving", this can be done by Partner Development Infrastructure (PDI) by throwing error messages while doing a "save".

Conclusion

This article introduced you on how to understand access determination in case of conflicts with role or page layout privileges. Now, you can perform quicker analysis in the event any issue arises.