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
Must be active
Construct a list of Underwriting Definitions based on the following criteria:
Unique Departments
Approval Type matches the Batch type (RFP/Renewal)
Contract Type matches the CM/PB Contract Type OR is empty
Definition is active
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
Department
Contract Type
Batch ID
Assigned To User
IsActive = False
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’
For Developers:
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’

For Developers:
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