Skip to content

Configuration Management

Configuration is one of the ways to tailor an IFS Cloud solution. While this page discusses the lifecycle management of configurations in particular, there is also general guidance on lifecycle management of tailorings.

Configurations have an inner and an outer lifecycle:

  • The inner lifecycle is how a configuration is managed within a single environment. How it is created (often in a draft state) and then made active (published) for all users or a group of users depending on the configuration context.
  • The outer lifecycle is about how a configuration moves between environments, on its own or together with other tailorings such as customizations.

This page is about the outer lifecycle for configurations. The inner lifecycle is described for each configuration type individually.


The configuration outer lifecycle flow is based on these principles:

  • Configurations are done (created, updated) in DEV (build place) or CFG (use place) environments
  • Configurations are stored in the customer solution repository for safe keeping so that the repository will always contain the latest and correct version of configurations and thus there is no need to store configurations separately anywhere else.
  • Configurations are promoted to UAT and PROD by manually importing them into those environments after the delivery (containing update to core or customizations) on which they depend as been applied to UAT and PROD respectively.

The configuration outer lifecycle flow is illustrated in the below picture.

Configuration Lifecycle Flow

  1. Configurations are recommended to be created in the CFG use place environment (1a), but it is also possible to create them in a DEV environment in the build place (1b). Which one to choose depends on the type of configurations. While some configurations such as custom entities and custom attributes are easily created and tested in either location, other configurations such as Workflows, Queries and Lobbies may be difficult to design and test/validate without having a full copy of the data from PROD.

  2. Configurations are exported and committed as individual exported items, or exploded Application Configuration Packages to the /nobuild/appconfig/<acp name> folder on a topic branch in the customer solution repository. This applies also to configurations (e.g. lobby elements and pages) that are not part of ACPs. Make sure you know which component and folder to use for storing them.

If multiple configurations and/or customizations are needed together to implement a wanted feature in the customer solution, then they are done on the same topic branch, and then merged into the master branch with a single pull request. That way all the things that are need for this feature of the customer solution are promoted through the lifecycle together.

  1. (optional) Manually import the configuration into UAT if needed for final testing/approval. Not shown in the illustration above.

  2. Promote the configurations along with any other work done on the topic branch to master using the pull request process.

  3. Order and apply a delivery which includes the target commit that contains the new/changed configurations and/or other items you want to promote into UAT and the PROD. This step can be skipped if the target commit only includes configuration changes (i.e. no code changes).

  4. Manually import the configurations into UAT after you have installed the delivery, so that any configurations that depend on customizations or other changes in the customization or core layers will work.

  5. Do the same (apply the delivery and then manually import configurations) into PROD once testing in UAT is completed.

If for some reason at any time a configuration change is done directly in UAT or PROD, then export that configuration and commit to the customer solution repository, just like you would have done if it was created in CFG.

Handling Configurations in Release Updates

When applying release updates, which contain new and changed functionality, it is likely that configurations will be impacted to some extent. To handle any such impact the following process is recommended.

  1. Follow the release update studio process to the point where the delivery containing the release update is applied in the CFG environment.
  2. Resolve any impact on configurations in the CFG environment using provided tools and capabilities such as configuration impact analyzer, rebasing of page designs, and lobby impact analysis.
  3. Continue from step 2 in the overview process above, nothing that in step 5 the delivery in question is the delivery that contains the release update.

Including Configurations in Deliveries for automated application to DEV, UAT and PROD

The recommended approach described above is relying on manual import of configurations to UAT and PROD (and any other use place environments). It is also possible to place exported configurations in the server/appconfig folder in order to have them automatically imported as part of the application of a delivery to an environment. A benefit of this is that configurations will be automatically imported to new DEV environments created for topic branches, or to new environments used in the Release Update Studio. The downside of this approach is that you need to create and apply a delivery to promote configurations e.g. to UAT and PROD environments, which takes longer (and requires a scheduled downtime window) than promoting configurations through manual import.

Consider this option for automated application of configurations when you have a lot of configurations that are "done" in the way that you are not actively changing them anymore.

Analyze Impact on Configurations

It is highly recommended to maintain all the configuration in the customer solution repository in the Build Place and perform the impact analysis via Configuration Analyzer.

In a delivery which includes changes from core and/or cust layers (eg. Feature Updates / Service updates) in addition to configurations, configuration impact analysis is recommended to be performed at build place before delivering to Use Place.

But, when there are no other layer changes except configurations, impact analysis may be performed at the Use Place itself.

Nobuild or Server Folders

For configurations which are kept inside the customer solution repository but are not intended to be delivered via Build Place, the extracted content of ACPs should be committed to: <component>/nobuild/appconfig/<acp name>


Configurations such as Lobby pages and elements that are not part of ACPs and that you also want to manually promot/import to environments should be placed in their respective folders under <component>/nobuild folder.

For configurations which are to be included in deliveries (they become part of the delivery and are applied together with the delivery), the extracted content of ACPs should be committed to: <component>/server/appconfig


Configurations such as Lobby pages and elements that are not part of ACPs and that you also want to include in deliveries should be placed in their respective folders under <component>/nobuild folder.