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, the
system withdraws all those cases that, according to the results of the previous phase,
are not required anymore. The second phase executes the following tasks: There are few extension points provided in this part of the process for financial
institutions to change the default behavior of the engine. During the initialization of requirement cases, the synchronization engine transfers
all the requirement relevant information, along with party data, routing information, and so
on. Additional information can be passed by extending the following rule: The 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. You can reuse requirements completed in previous customer journeys for the same party
and under the same context (the same contracting party). To enable or disable this functionality based on the case data or the journey type, use
following when rule: Use the rule to let the engine know whether to reuse requirements
or not. The engine receives the requirement as an input, and it
must return a boolean output parameter. If the parameter goes
out with true, the functionality is
enabled. Otherwise, the functionality is disabled. Use this rule to implement logic that may depend on the journey
type or 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: To implement the last of the checks, to determine whether the requirement definition is
changed since the requirement is resolved, the system uses the Satisfaction Logic
Indicator. This indicator is a string that is set at the time of the resolution of the
requirement and which 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. So any
update in the definition of the requirement prevents the reuse of previous instances of
requirements of that type. While the conservative approach works well for many financial institutions, you might
want to make changes and create a more sophisticated logic to generate the 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 the Satisfaction Logic Indicator, use the following rule: The rule receives the requirement that is considered as input and
generates 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 previously
provided documents to satisfy the requirement is expired or stale. If that is the case,
the requirement cannot be reused. To change this behavior, extend the following
rule: The rule returns the false value by
default, so the requirement with a past valid end date cannot be
reused. Modify the rule to return the true value
if the system must ignore the expiry or stale or both dates of
the documents within the requirement. When you created the requirement case, the system checks if the customer has already
provided documents requested by the requirement in the past. The system automatically
attaches 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. To satisfy the
requirement that only one document is required, the case leaves the initial stage of
Satisfy and goes into the next Data
capture stage. If the passport went already through the
Data capture stage in the past, the system determines
that the second stage is not required and makes the case progress to the third one, the
Verification stage. However, if the logic of the requirement is different and requires both documents,
passport and driver license, the system can attach the document automatically but is not
able to make it go beyond the first Satisfy stage, where
the case waits for a second document to be uploaded. To change some of the behavior of this functionality, use the following rules: The rule determines whether the system must reuse or not the
expired or stale documents. By default, the rule returns the
false value, so the system does not
consider expired documents. Change this rule to return true if you want to enable the reuse
of expired or stale documents. When the system is configured to consider only documents that are
expired, the rule uses the current execution date as the date to
compare against the expiration or stale date of the
document. Modify the rule if you want the system to ignore documents
sometime before the actual expiration or stale, or both dates
(for example, three or six months later). Use the rule to avoid the reuse of documents of a certain type.
By default, document reuse is active for all document types. Modify the rule to control which document types must be
considered for document reuse. Pega Client Lifecycle Management and KYC executes the requirements synchronization engine
in most of the synchronizations with the Master Profile. To change the behavior of the functionality and restrict its execution to only certain
stages or steps in the process, use the following rules: The rule acts as a general switch for synchronization. The rule
can be turned on and off based on certain conditions. By
default, it is always turn on. Modify the rule if you want to disable the synchronization from
your application without modifying all the invocation points or
doing it selectively under certain circumstances. The decision
should be based on case data. 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. The rule gives some control to processes that want to skip or
include the synchronization based on certain conditions. The
calling process can set the
bTriggerRequirements property that the
rule checks to skip or not the synchronization. Use the bTriggerRequirements property to
enable or disable the synchronization from specific
processes.Passing additional information to requirement cases
Rule name Rule type Usage RNGSyncReqCaseCreate_Ext Data transform Configuring requirement reuse
Rule name Rule type Usage RNGIsReqReuseEnabled Data transform Rule name Rule type Usage RNGSetSatisfactionLogicIndicator Data transform Rule name Rule type Usage RNGIsReqReuseInvalidDate When Configuring document reuse
Rule name Rule type Usage RNGIsReuseOfStaleAndExpiryDoc When RNGGetReferenceDateForDocsReuse Data transform RNGAssessDocumentReuse Data transform Invocation points
Rule name Rule type Usage RNGSynchronizeRequirementsEnable When SkipSynchronizeRequirements Map value ReadyToTriggerRequirementSubcases When
Previous topic First phase of synchronization: determination Next topic Requirements case