Approval dependencies
Approval Dependencies define the hierarchy of Approval records using a system of parent-child dependencies. If an Approval record is dependent on another Approval record (considered the parent record), the dependent Approval record cannot be accessed until the parent is approved. As the parent is approved, escalation of dependent Approvals takes place (now generating Task Triggering), making them accessible to the user for Approving/Declining.
The Approval process: Accepting the RFP Batch
The Accept link (or the link configured to execute the CM.Accept business rule) is selected [CM Pipeline].
CM.Accept rule is executed.
|
| •
|
The active ‘Submitted’ RFP Batch is located |
|
| •
|
The ‘Create Approvals’ process is executed |
|
| •
|
All existing Approvals {in the workspace} are inactivated (IsActive = False) [Db] |
|
| •
|
The Contract Type found on the Client Master is retrieved (if missing, the Batch Contract Type is used) |
|
| •
|
Client Approval Dependencies are inserted: |
|
| •
|
Any existing Approval Dependency records in this workspace are deleted [Db] |
|
| •
|
New Approval Dependency records are inserted in this workspace [Db] based on the following criteria: |
|
| •
|
The associated Underwriting Definition must match the Batch Type (e.g., RFP) |
|
| •
|
The associated Underwriting Definition must match the Contract Type OR have an empty Contract Type |
|
| •
|
Construct a list of Underwriting Definitions based on the following criteria: |
|
| •
|
Approval Type matches the Batch type (RFP/Renewal) |
|
| •
|
Contract Type matches the CM/PB Contract Type OR is empty |
|
| •
|
For each Underwriting Definition in the list: |
|
| •
|
Determine if an Approval can be created from this Definition: |
|
| •
|
If the Definition Department is NOT “Benefits” |
|
| •
|
OR the Health Benefits field on the Client Master = “Yes” |
|
| •
|
If an Approval record CANNOT be created from this Definition, move to the next Underwriting Definition |
|
| •
|
If an Approval CAN be created: |
|
| •
|
Get the Assigned To User (either from the Assigned To or the Assigned To Ref on the Definition) |
|
| •
|
If the Assigned To User CANNOT be located, do not create an Approval for this Definition |
|
| •
|
If the Assigned To User CAN be located, then |
|
| •
|
Attempt to locate an existing Approval record (in this workspace) which matches this Underwriting Definition |
|
| •
|
If a matching Approval record is found |
|
| •
|
Set its status to ‘Pending’ (or ‘Waiting’ if it is a dependent) [Db] |
|
| •
|
Set IsActive = True [Db] |
|
| •
|
No Task triggering is generatedIf a matching Approval record is NOT found |
|
| •
|
Create an Underwriting Approval record using the Department, Assigned To, Batch ID, Contract Type, Dependency Count information from the Definition [APP Pipeline] |
|
| •
|
Apply Row Security to the record [Db] |
|
| •
|
Generate the [CloneTask]“APP_department” |
|
| •
|
Next Underwriting Definition |
Approval ‘Approve’
After ‘Accepted’, Approvals are in place based on the methods previously described. When an Approval is ‘Approved’
If there are Approvals that must be approved prior to approving this Approval, an error is thrown “This record is waiting for the following Approval(s) to be ‘Approved’”. This should not be the norm as there are user interface controls in place to properly display the parents of dependent Approvals before access to the dependent is granted
If the Department is ‘Risk’ and the Batch contains Codes Requiring Review, an error is thrown “This Pricing Batch cannot be approved because it has associated Pricing Codes that are marked for review”
If no validation errors are encountered, Approvals are evaluated:
|
| •
|
For Developers: the appropriate Approval Workflow Object is instantiated. This object contains specific methods implemented to act upon Approvals based on the type, such as Pricing, No Pricing) |
|
| •
|
If the Approval has changed to ‘Approved’ |
|
| •
|
The Approved By User, Date and Time approved are set [Pipeline]. |
|
| •
|
[CloneTask] ‘APPROVED_department’ is generated. |
|
| •
|
Dependent Approvals statuses are escalated. |
|
| •
|
A list of dependent Approvals (if any) is retrieved. |
|
| •
|
For each dependent Approval: |
|
| •
|
The Assigned To User is located. |
|
| •
|
If an Assigned To User is found, [CloneTask]‘APP_department’ is generated. |
|
| •
|
The dependent Approval status is progressed to ‘Pending’ [UnderwritingApproval Pipeline] No rules are executed; this is only a mechanism to allow task triggering to be generated. |
|
| •
|
If all Approvals are ‘Approved’ |
|
| •
|
An overridable method ‘SetApprovedWorkflow’ is called. This allows candy solutions to perform some custom actions at this point in the process |
|
| •
|
An overridable method ‘OnHasAllApprovals’ is called. This allows candy solutions to perform some custom actions at this point in the process |
|
| •
|
In PEO, the ‘SetApprovedWorkflow’ method |
|
| •
|
Sets CM and Pricing Batch status to ‘Approved’ [Db] |
|
| •
|
Update Comparison Batches [Db] |
|
| •
|
[CloneTask]‘CM_Approved’ is generated |
|
| •
|
If all Approvals have NOT been ‘Approved’ the process remains in its current state awaiting additional Approval activity |
Approval ‘Decline’
When an Approval is ‘Declined’
For Developers: the appropriate Approval Workflow Object is instantiated
If the Approval has changed to ‘Declined’
|
| •
|
An overridable method ‘SetDeclinedWorkflow() is called. This allows candy solutions to perform some custom actions at this point in the process |
|
| •
|
In PEO, the ‘SetDeclinedWorkflow’ method |
|
| •
|
Sets the CM and Pricing Batch status to ‘Prospect’ and ‘New’ respectively [Db] |
|
| •
|
Updates the Comparison Batches [Db] |
|
| •
|
Sets the Pricing Batch Date Declined field to the current date [Db] |
|
| •
|
[CloneTask]‘DEC_department’ is generated |
|
| •
|
All other Approvals remain in their current state and status |