Skip to content

Configuration Contexts


By default configurations are stored centrally and overrides the deployed standard application. In contrast to a user personalization that is performed individually by a user and stored in the personal profile for individual use; a configuration is applied to the environment as if it was a customization. All users in the system will run and be affected by these changes. Configuration Context is a concept to make the configuration layer more flexible. It makes it possible to develop and provide different configuration versions of the same application object. In other words, configurations can be made and provided for different context.

The context selector is located in the top of the designers. One use this picker to select the context for which the configuration should be created and saved.

Global Context

The default or base configuration context is the global context. Configurations in the global context affects all users in an environment in the same way. Global configurations is also something that the user will run as long as nothing else is specified in terms of explicit navigations or context mappings. With configurations published users will either run a specific context or fallback to global context. The global context is acting as a customization and can't be circumvented.

Custom Contexts

Besides the global context one can define any number of custom contexts to store configurations for. Custom contexts are segmented from each other but is based upon the global context. Simplified, this means that if you have made layout configurations for two custom contexts X1 and X2, and also a configuration for global. A user running the application that is connected to context X1 will get configurations from X1 and global. This while a user running the application and is connected to X2 will get configurations made for X2 and global. No user will ever get a combination of X1 and X2.

In contrast to the global context. A user running the application will not get a configuration for a custom context if that is not specifically defined. This can be defined either by an explicit directive on a navigation request; e.g. navigator entry, lobby element link; or implicitly by mapping a user or group of users to a configuration context.

Define new Custom Contexts

Defining a new specific context is done in the configuration context selector. Drop down the list of available contexts and enter a context identifier. This is how the configuration context works. The context is simply an identifier or label if you like, that you define and then is stored together with the configuration. There is no specific base data storage where one defines configuration contexts that is then used. You define the identifiers when and where they are needed.

Syntax: The identifiers are case sensitive and can, but should because of practical reasons not, contain spaces.

How to reach a configuration of a page made for a Custom Context

When configurations is made for the global context then this configuration will be used as soon as an application user navigates to the page in any way; e.g. ; navigator, bread crumb, internal or external links. The global configurations are, like described before, the same as if the application was customized. The global configuration is used as if it was core.

For Custom Context it is the opposite. No user will ever use a configuration from a specific context if not specifically defined. There are two ways to do this.

  • Implicit by mapping users or user groups to a configuration context.
  • Explicit navigation directive. Specify the configuration context to be used directly on a navigation URL as an attribute called "scope"
https://<environment URL>/main/ifsapplications/web/page/Customer/Form;scope=A10

Map a Custom Context to a user or a group of users

A context can be explicitly defined on a navigation request. This is useful in cases where for example multiple versions of the configuration should be used by the user depending on choice. Example of this could be different configurations of the same assistant. Depending on what should be performed the user could access these different version from different navigator entries. A more common scenario would be that different parts of the application is configured to suit a specific group of users. In this case explicit navigation is not a practical solution. In this scenario there might exist several configurations for the same page but only one is expected to be used by a specific user. Depending on which company the user is connected to or which user groups the user is member of; the user should get the configurations made for a specific scope that applies to the page navigated to.

This is where mappings of configuration contexts comes into play. With mappings you can map a context to a specific user or a group of users, where the mapped context becomes the default context over global where applicable. This means that for each navigation the framework will use configurations for the specific scope if it exists or the global scope if it exists and core application if no configuration exists.

The framework will use contexts in the following order:

  1. Explicit context directive on an URL
  2. Mapped default context
  3. Global Context
  4. Application Core

Administrate Context Mappings

Configuration context mappings are specified in the administration form with the same name.


Specify which context you want to map. The dropdown list show all context identifier currently used for configurations. It is also possible to map context identifiers not yet used. This is if one wish to setup the default context for users before configurations is done. A reason to do so is because if a user have a default context mapped this context will be default selected in the context selector in the designers.


This is just a description for the context identifier mapping. The description is currently not used for anything outside this admin page at the moment.


A condition that is evaluated for each navigation to determine if the context mapping should apply or not.

  • Condition Attributes

The different condition attributes that can be used to mapp a context are: Company, WageClass, Ledger, UserGroup, User. The attributes are case insensitive and can be written as: Company, COMPANY, company. - Condition Operators

The operators that are supported are: = (equals), != (not equals), And, Or. Operators like the attributes is case insensitive and can be written as: AND, And, and. - Condition Values

Condition values are the actual values that the attribute are compared against. Values are case sensitive and needs to be written as they are defined; i.e. ; if a user group is named DemoUsers then it needs to be written as such in the condition. Values is normally specified without quotes but if the value contains spaces it needs to be enclosed with either single or double quotes. "Demo Users" or 'Demo Users' - Logical Groups

The condition supports logical groups enclosed by parentheses. The normal execution rule of the condition is from left to right. When it is needed to control the order of how the condition is evaluated parentheses can be used to group parts of the condition together.

Example: You are connected to company 10. In this example the whole condition would evaluate to false for you.

company = 10 AND user != SOMEONE_ELSE OR company = 11 AND user != YOU

When adding parentheses to control the evaluation then the condition will evaluate to true.

(company = 10 AND user != SOMEONE_ELSE) OR (company = 11 AND user != YOU)
  • Spacing

Spacing in the condition is ignored so any combination of spacing is valid. x=y, x = y, x= y. Only place where space is required is around the AND and OR operators.

Once a new context mapping is added, the context mapping cache should be cleared in order for the context mapping to work.

Ambiguous Navigation

As the section "Map a context" describes we can map a custom context to a user or a group of user to be used if the navigation target have configurations for that context. It is possible to configure mappings in a way that more than one configuration map to the navigation target. In these cases the framework have no way of knowing which configuration is intended, hence can't resolve the request. The user will be confronted with an error that the request was resolved as ambiguous and that the administrator should be contacted.

A request for configurations is ambiguous if: More than one specific configuration context is mappable for the current request and there exists configurations stored for more than one of these contexts.

Example: User A is navigating to page X and while doing so both specific context Y and Z maps to A. At this time page X have only one configuration stored and that is for Y. In this case the page will show without error because only one configuration was applicable.

Same example as above but this time page X also have a configuration for context Z. At this time user A will get an error message stating that the navigation was ambiguous and the administrator should be made aware of the situation.

Tip: User Groups is a practical and convenient way to segment users and contexts. User Groups is also used to segment security but the goals of the two might not intersect. So if the same user groups that are used for segmenting the security model is used to map configuration contexts. Then it is likely that user groups administration becomes hard to overview and maintain. You should consider to create and administrate separate User Groups that is used only for configuration context mappings.

Conceptual Example

There are three layers included in the above image.

  1. Core layer (IFS Product Development delivered)
  2. Global Context layer
  3. Scope A and Scope B layer

Scope A and Scope B are the defined scopes with Global Context Conditions. (Company=11 and Company=10)

If we consider the users in Company 10, Company 11 and Company 12 as per the image, different configurations will be available to different sets of users depending on the how the Scopes are defined.

Global Company Available Configurations
Company 12 ab and x configured artifacts from Global Context Layer and c artifact from Core Layer
Company 11 a configured artifact from Scope A layer since company =11 is the context condition for Scope A, b and x as configured in Global Context Layer and c from Core Layer
Company 10 y artifact added in Scope B, a b and x as configured in Global Context Layer and c from Core Layer

Note : If any changes are made in the Global Context, these changes will apply to the other defined contexts as well.

Example Scenarios

  1. No configuration made on a page
        User gets Core (IFS Product Development delivered) version of the page

  2. Configuration made on a page in a global context
        Users get global configuration

  3. Configuration made on a page connected to Scope A
        Users that navigate to the page through a link with ;scope=A in the URL gets the configured page defined in Scope A.

  4. Configuration made on a page connected to Scope A and Scope A condition is ’company=10’
        Users that navigate to the page through a link with ;scope=A in the URL get the configured page in Scope A.     Users with global company = 10 gets the configured page in Scope A by default
        Users not affected by condition in Scope A get global configuration if such exist (users with global company !=10)

  5. A page has configurations in both Scope A and Global context
        User navigating through a link or that has has global company = 10 will see configurations made in Global context and Scope A.     The configuration in the ”highest” layer will be available for the users.