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).

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.

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.