You must select a collection rule for each module to define which processing should take place. This also provides traceability and allows you to drill down to actual components in the application.

You must complete the following fields for each module:

• Module – brief name or description of the module. This description is used by the application whenever there is a reference required for the module being processed, for example, Claim Audit.
• Identifier – a key assigned to this module. This identifier is stored for references to the module and is used as a lookup value for the module. It lets you modify the description without worrying about the reference to the module. Once you assign and use it, you should not modify it.
• Process – a flow associated with the module. Select this process from a drop-down list of available flows.
• Process Type – the type of module (Stub, Pega, and External) as it relates to the application.
• Measurement – an indicator that defines whether a measurement should be captured for this module.
• Audit – an indicator that defines whether any audit information should be reported for this module.
• Bypass – an indicator that defines whether to bypass processing of this module (used for testing).
• Module Bypass Table – the bypass table used for identifying what information on the claim can cause the module to be bypassed.
• Module initialization – A previously defined Collection rule that can be used to initialize any values pre-run.
• Module finalization – A previously defined Collection rule that can be used to finalize any value post run.
• Module next step – A previously defined Collection rule that can be used for the below purposes:
  • Restart Module
  • Restart Module Sequence
  • Restart Orchestration
  • Exit Sequence
  • Exit Orchestration
  • Force Claim to Error workbasket