Second phase of synchronization: implementation
The second phase of the synchronization engine takes care of the creation and withdrawal of requirement cases as per the documentary requirements determined during the previous phase.
In this phase, the system iterates through all the requirement sets and requirements that are deemed applicable before and creates or reuses cases for them. In addition, it withdraw all those cases that, according to the results of the previous phase, are not required any more. The main tasks executed in this part of the process are:
- Case initialization
- In those situations where the synchronization engine determines that a new case is required, the system creates the new instance and initialize it with all the data required for its later processing.
- Case reopening/reuse
- If the system determines that the requirement is been already managed in the current customer journey and, therefore, there is a case for it in the system, it will process to reuse it (if it is in flight) or reopen it (if it was already resolved).
- Case withdrawal
- After the system has ensured that all applicable requirements have their corresponding case, it will withdraw all those cases that were created in previous runs of the synchronization engine and whose requirements are not applicable any more.
- Requirements reuse
- If a given requirement was processed before for the same party and within the same context in a previous customer journey, it can be reused.
- Documents reuse
- As part of the case initialization, the system checks if the targeted party has already some of the documents requested in the requirement. If any match is found, it is automatically attached to the case and the case made progress to the next applicable stage.
There are few extension points provided in this part of the process for financial institutions to change the default behavior of the engine.
Passing additional information to requirement cases
During the initialization of requirement cases, the synchronization engine transfer all the requirement relevant information, along with party data, routing information, and so on. Additional information can be passed by extending the following rule:
| Rule name | Rule typ | Usage |
|---|---|---|
| RNGSyncReqCaseCreate_Ext | Data transform | This rule receives the requirement definition and the new requirement case, and it is executed in the context of the customer journey case. Modify this rule to pass additional information to the newly created requirement case. |
Configuring requirement reuse
It is possible to reuse requirements completed in previous customer journeys for the same party and under same context (the same contracting party).
To enable or disable this functionality based in the case data or the journey type use following when rule:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGIsReqReuseEnabled | Data transform | Use this data transform to let the engine know whether to reuse requirements or not. It receives the requirement being considered as an input and it should return an output boolean parameter. If the parameter goes out with true, the functionality will be enabled. Otherwise, it will be disabled. Use this rule to implement logic that may depend on the journey type or in the type of requirement. |
If the functionality is enabled, the system will search in the requirements metadata table for any completed requirement created in the past that meets the following criteria:
- Same party
- The requirement is for the same party.
- Same context
- The main journey was for the same contracting party.
- Same requirement
- Same name as per requirement definition.
- Same scenario
- The requirement was resolved with the same scenario that is currently active.
- No changes in the requirement
- The requirement definition has not been changed since its use.
To implement the last of the checks, the one to determine whether the requirement definition is changed since the requirement is resolved, the system uses Satisfaction Logic Indicator. This indicator is a string that is set at the time of the resolution of the requirement and that is later used during the requirement use logic.
By default, the system sets the last update time of the requirement definition (pxUpdateDateTime) as the Satisfaction Logic Indicator. This means that any update in the definition of the requirement will prevent the reuse of previous instances of requirements of that type.
While this conservative approach works well for many financial institutions, you might want to make changes and create a more sophisticated logic to generate this string. For example, generate a hash from the satisfaction logic and its associated documents to give more flexibility to the reuse process and therefore reduce the operational load of the teams.
To implement your own Satisfaction Logic Indicator, look at the following rule.
| Rule name | Rule type | Usage |
|---|---|---|
| RNGSetSatisfactionLogicIndicator | Data transform | This rule receives the requirement that is considered as input and generate an output parameter with the Satisfaction Logic Indicator. Modify this rule to implement a more complex logic that can maximize the benefits of the requirements reuse functionality. |
At the time of the assessment, the system also considers if any one of the documents that was previously provided to satisfy the requirement is expired or stale. If that is the case, the requirement will not be reused. To change this behavior, extend the following rule:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGIsReqReuseInvalidDate | When | This when rule returns false by default. Which means that the requirement with a past valid end date cannot be reused. Modify this rule to return true, if the system should ignore the expiry or stale, or both dates of the documents within the requirement. |
Configuring document reuse
When a requirement case is created, the system can check if the customer has already provided in the past the documents that are requested by the requirement. The system automatically attach all those documents that could previously exist and, depending on the status of the document and the satisfaction logic, make the case progress to the appropriate stage.
For example, if a requirement expects either a passport or a driver license from a given party, and that party already provided the passport in a previous journey, the system can automatically attach the document and try to make the case progress. Given that only one document is required to satisfy the requirement, the case will leave the initial stage of Satisfy and go into the next one, data-capture. If the passport went already through data-capture in the past, the system will determine then that this second stage is not required and will make the case progress to its third one, verification.
However, if the logic of the requirement was different and required of both documents, passport and driver license, the system would be able to automatically attach the document but would not be able to make it go beyond the first stage, Satisfy, where the case would wait for second document to be uploaded.
It is important to note that under this model the requirement case cannot go automatically beyond the verification stage. That stage requires of a user to confirm that the document that was uploaded in the past is valid for the current requirement.
To change some of the behavior of this functionality, see the following rules:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGIsReuseOfStaleAndExpiryDoc | When | This when rule determines whether expired or stale documents should be reused or not. By default, it returns false so system does not to consider expired documents. Change this rule to return true if you want to enable the reuse of expired or stale documents. |
| RNGGetReferenceDateForDocsReuse | Data transform | When the system is configured to consider only documents that have not expired, it uses the current execution date as the date to compare against the expiration/stale date of the document. Modify this rule if you want the system to ignore documents some time before the actual expiration or stale, or both date (for example, three or six months later). |
| RNGAssessDocumentReuse | Data transform | Data transform that can be used to avoid the reuse for documents of a certain type. By default, document reuse is active for all document types. Modify this rule to control which document types should be considered for document reuse. |
Invocation points
Pega Client Lifecycle Management for Financial Services executes the requirements synchronization engine in most of the synchronizations with the Master Profile. To change this behavior and restrict its execution to only certain stages or steps in the process, see the following rules:
| Rule name | Rule type | Usage |
|---|---|---|
| RNGSynchronizeRequirementsEnable | When | This when rule acts as a general switch for the synchronization. It can be turn on and off based on certain conditions. By default, it is always turn on. Modify this rule if you want to disable the synchronization from your application without having to modify all the invocation points or to do it selectively under certain circumstances. The decision should be based on case data. |
| SkipSynchronizeRequirements | Map value | Map value that determines whether the requirements synchronization needs to be run during the Master Profile synchronization based on the type of case where it is executed. Modify this rule to enable or disable the requirements synchronization engine based on case type. |
| ReadyToTriggerRequirementSubcases | When | This when rule gives some control to processes that wants to skip/include the synchronization based on certain conditions. The calling process can set a property called bTriggerRequirements that will be then checked by this when rule to skip or not the synchronization. Use the property bTriggerRequirements to enable or disable the synchronization from specific processes. |
Previous topic First phase of synchronization: determination Next topic Requirements case