To upgrade the functionality, you must activate 2G, create new requirements, and configure the synchronization engine accordingly.

The first step in the process is the activation of 2G. This configuration ensures that all new requirements are created using the new capabilities and that the engine follows the new rules.

1. In the navigation pane of Dev Studio, click Records.
2. Expand the SysAdmin category, and then click Dynamic System Settings.
3. In Dev Studio go to RecordsSysAdminDynamic System Settings.
4. In the Dynamic System Settings tab, click the PegaCLMFS Requirements/ActiveGeneration rule.
5. Change the value to 2.
6. Click Save.
   If you need to continue making changes under the current session, force the loading of the configuration by flushing the data-page D_ReqConfiguration.

The new generation of functionality uses a separate set of requirement sets, requirements, and documents.

At the time of activating the functionality in the production environment, there are two active sets of rules:

Legacy requirements

The system uses the requirement sets, requirements, and documents defined before activating 2G to resolve the in-flight cases that might exist at the time of activation.

New requirements

The new engine uses the new set of rules to create new requirement cases taking advantage of all the new capabilities provided by 2G.

If you are using the out-of-the-box requirements shipped with Pega Client Lifecycle Management and KYC, these two sets are immediately available after installing the version of the product. If, on the contrary, you are using your own defined requirements, you need to create that new set of rules.

The new functionality introduces an entirely different paradigm. Trying to replicate the current arrangement of sets, requirements, and documents in 2G without adopting that new paradigm can have significant implications in terms of performance and operations.

The following differences to be considered at the time of creating the new set of rules for your organization:

Requirement-document cardinality

In the new version, requirements can manage multiple documents. The requirements can also manage different business scenarios and a satisfaction logic that can dynamically change as the data of the case changes. The new approach significantly changes how to use the requirement sets and requirements.

In the previous versions, a requirement set is used to represent a business requirement (for example, proof of identity). The requirement is the way to link it to a specific document. In the new version, the requirement can manage by itself a whole business requirement, and that gives to the requirement set a completely different purpose: grouping together related business requirements.

Requirement set purpose

In the previous version, all requirement sets are considered by the synchronization process. In 2G, the synchronization engine can be configured to look only at certain groups of requirements based on business rules. That grouping of requirement sets is implemented by what is called the purpose.

For example, you have two different groups of requirement sets, one group created for customer identification and another for tax purposes. The customer identification sets do not need to be considered in an offboarding journey.

For example, we can tag a group of requirement sets created to collect documents for customer identification with a purpose Customer Identification Purpose (CIP). We can then configure the engine to consider the CIP purpose only under certain circumstances (for example, in all journeys except in offboarding). The purpose concept gives us the ability to segregate requirement sets and achieve this type of configuration.

For the actual creation of requirement sets, requirements and documents, you can use Dev Studio or the Requirements Portal. If you are going to use the latest one, you must configure it to generate the new rules under the appropriate rulesets. For more information, see Configuring ruleset for the portal, in chapter Requirements definition).

After the new requirements are defined, configure the synchronization engine. If you are using the requirements that come out of the box with Pega Client Lifecycle Management and KYC, the synchronization engine is already configured. If you are using your own requirements, you must configure the engine to ensure they are considered during the synchronization.

For more information how the engine works and what you must configure, see the chapter Synchronization engine. Take under consideration the following tasks:

Configuring the relevant purposes

Configure the engine to consider the new requirement sets that you might created.

Building up the requirement set locators

Ensure that the engine knows which locators must be used for each specific purpose.

Adding more information to the context

Ensure that the engine has all the information that to run the applicability rules of your new requirements.

The new version of the requirement case type drives a new functionality that is implemented in the requirement cases. The new version is a circumstanced version of the legacy case type, and that might not be accessible from your implementation layer.

To ensure that your application uses the right version of the case type, make a copy of the circumstanced version. For more information, see "Copying requirements case type to the new class structure" in the chapter Configuring the application.

• Upgrading from 1G into 2G