Configuration sets
| Configuration sets | |
|---|---|
| New URL | https://docs.pega.com/bundle/platform-88/page/platform/app-dev/creating-configuration-set.html |
| This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location. | |
Configuration sets
Application configuration is a critical piece of an as-a-service-application yet introduces many challenges to application developers. These challenges range from upgradability to backward compatibility to visibility and change management. Configuration sets eliminated those challenges with a new, unified framework to provide targeted application configurability to end users without the need for overrides or authoring changes. This flexibility allows application developers to build robust, configurable applications without sacrificing critical aspects of keeping clients up to date with the latest in their applications.
Sample use case - providing an approval threshold
One common type of configuration we often see in applications is an approval threshold. In the case of a journey involving cost, we often see this approval threshold be a dollar amount used to control levels of approval. For example, we have a loan request journey. For all loans over $50,000, we must have an additional VP level approval. In this case $50,000 is our approval threshold. The problem is that every client may have different approval thresholds or even different dynamic ways of retrieving that value. For example, a client A has a threshold of $75,000 where a client B's threshold is $25,000. Additionally, we may even have a client C for whom the approval threshold is calculated based on the credit score of the loan applicant. It is impossible for the application developer to build a solution that catches all of the possible approval threshold values. Allowing clients to change the references or definition of that threshold, introduces significant backward compatibility and updatability issues which may leave the client stuck on an old, outdated version of the application. Providing a layer of abstraction of calculating this value with configuration sets eliminates the complexity of a traditionally challenging problem. By creating a configuration for our approval threshold and referencing it in our loan request journey, each client can provide their own value for that threshold without ever having to change the underlying application behavior or references.
Before you begin
Configuration sets are now a part of the Pega Platform starting in version 8.6. There is a feature toggle for configuration sets which can be used to turn the feature on or off for the application.
Process/Steps to achieve objective
When creating new configurations in your application, the first step is to create a configuration set for each of the configurable features within your application. The best practice is to align these sets with application features and not case types. Each configuration has a scope and the platform provides mechanisms to view by case type (if needed) so the features should be thought of from the end user perspective. What is the logical grouping of business features within an application? An example of this can be found with Pulse. Pulse has a variety of different configurations ranging from types of messages to display options. These configurations range across many different case types and classes. Trying to group by case type would provide a confusing disparate experience for the application end user. Instead, grouping these configurations into a single set called Pulse or Collaboration provides a clean, understandable grouping.
Be sure to provide meaningful names and descriptions for each settings with a given set. Description is shown in the end user Administration page and is critical for end users understanding the impact of changing a given configuration. Similarly, ensure the setting type reflects the expected values of this configuration. Setting type is used to validate the default values and end user values. If you have a default value that is an integer but you expect text values from your end users, text is a better selection for a type than integer since text encompasses all expected values. It is also important to remember that settings originally defined as scalar default values can be updated to be calculated. Setting type is a critical piece of keeping backward compatibility.
Configuration sets automatically track changes in between versions. This provides transparency into the new configuration changes in between versions. Before deleting a configuration, ensure that you consider the ruleset version of the configuration. Deletion is only allowed when the existing ruleset version in which the configuration was created is unlocked. All other "deletions" of a configuration are deprecations to ensure backward compatibility. For all applications allowing rule authoring to their clients, it is important to remember that those clients may have custom references to the configurations defined in your application. For any settings that you do not want to be leveraged outside of your application, provide the appropriate security.
Results
After leveraging configuration sets, applications can provide targeted business configuration to their end users without the need for rule overrides or authoring. This method of configuration provides upgradability, visibility and easy maintenance to provide a true as-a-service application.