Overview of Context Layers
You can use context layers to control which specific set of users your application changes apply to. Make sure you use a context layer to make application changes and set your sandbox to the correct context layer.
A sandbox is a testing environment that sets apart untested changes from the mainline environment so that these changes don't affect the mainline metadata or other users in the environment. You set the context layer while creating your sandbox. If you select a context layer that’s not Site, make sure the context layer of your sandbox is supported by the page you want to edit. Otherwise, you won’t be able to edit the page. You must also activate the configuration tools you want to use in your sandbox. The context layers for all selected tools are set as Site by default. So the changes you make using these tools affect all users. If you plan to use Page Composer in your sandbox and edit pages at a layer other than Site, you need to create a sandbox just for that layer and activate only Page Composer in it.
Changes made using the User Interface Text tool apply to all layers, not just the Site layer. Suppose you create a sandbox named SandboxA, activate the Page Composer tool, and set the context layer to the Job Role layer. Then you create a new string, Program Choice using the Page Composer tool in SandboxA and publish it. After that, suppose you create another sandbox named SandboxB and activate the User Interface Text tool in it. Using this tool, you replace the word, Program Choice with Campaign in SandboxB, and publish it. In this case, the string, Program Choice is changed to Campaign in all layers, including the Job Role layer.
Available Layers
Different product families have different context layers. But, every application has these layers:
-
Site: Changes made in this layer affect all users of the application.
-
User: Changes made in this layer affect just one specific user. But, you can't use this layer to make changes for other users. Personalizations are stored in this layer, and users can make personalizations only for themselves.
Here are the layers you can use when you configure different product families:
-
Customer Relationship Management
-
Site
-
External or Internal
-
Job Role
-
-
Human Capital Management
-
Site
-
Country
-
Organization
-
Time Card Layout
-
-
Default Layer
-
Site
-
How Layers Work
Layers are applied in a specific order.
-
User
-
External or Internal
-
Job Role
-
Site
You won't see changes that were set at a layer that's higher in the hierarchy. The higher the level, the more specific its context is. Layers at higher levels exist within the scope of the layers below them. This means that when a value is set for a context layer, it's set within the scope of the context value for the layers below it.
You can have multiple configurations for an object or a page at the same time, but this is possible only when either of these conditions are met:
-
Configurations are in different layers
-
Configurations are in the same layer, but the layers have different context values
When a user opens an object or a page, the configurations at the highest layer applicable to an object or a page are given precedence. Let's say you added three columns to a table and then configured these columns for each context layer in this way:
-
At the Site layer, you added three columns to the Sales table, namely, Promotion Name, Sales Points, and Partner Name.
-
For the external developer, the Sales Points column is hidden.
-
For the internal sales role, the Sales Points column isn't hidden.
Liam, who's an internal sales representative, personalizes this page for himself and hides the Sales Points column.
This is how different users see the column:
User |
Sees Sales Points Column? |
---|---|
Internal sales role |
Yes |
External developer |
No |
External recruiter |
No |
Liam |
No |
Here's a visual representation of these configurations in different context layers and values.