NOTICE: You are in the old ClientSpace Help system. Please link to the new ClientSpace Help here https://extranet.clientspace.net/helpdoc/home/ClientSpace.htm

PEO Underwriting Approval Process

Owned by Tony Hayes
Last updated: Oct 30, 2015
10 min read

Summary

This document describes the newly-designed Underwriting Approval process for RFP and Renewal Batches.  It is intended for Business Analysts to aid in understanding the process and configuration of the system.  It identifies the technical features of the soon-to-be-released Underwriting Approval process. 

  

 

Underwriting Approval Process Overview

The Underwriting Approval Process has been redesigned.  The overall concept is:

  • To create Approval records based on specific Pricing Batch criteria (which it has always done)
  • Re-use existing Approval records whenever possible to preserve audit data (which it has done although not always appropriately). 
  • Resolve shortcomings in the existing process when changing Contract Status after Approvals have been generated (which left some Approvals in place although they were not applicable to the business)
  • Add Task Triggering to Dependent Approval Escalation

 

The process is designed so that certain key Milestones generate Clone Tasks or perform dataform pipeline ‘Saves’ so that Task Triggering can be initiated.  Other ‘minor’ Milestones are performed directly in the database which will NOT generate Task Triggering.  In this document, the following conventions are used to identify which type of action is performed for those Milestones:

  • [Db] indicates a database action which will not generate Task Triggering
  • [CloneTask] indicates a custom Clone Task action is broadcast
  • [Pipeline] indicates a record is either added or modified through Business Logic causing Task Triggering to fire

 

Document Overview

The following Processes are evaluated in this document:

 

Underwriting Definitions and Their Relation to Underwriting Approval Records

Underwriting Definitions reside in the Admin workspace.  They are used as templates to generate Underwriting Approval Records for a client workspace.  One Approval record is generated for each Underwriting Definition that matches the following criteria:

  • UD (Underwriting Definition) unique Department
  • UD Approval Type = RFP or Renewal
  • UD Contract Type = CM Contract Type OR is empty
  • UD IsActive = True

 

Underwriting Definition configurations are managed by unique Department/Approval Type/Contract Type:

  • For a given Department, a Definition can be created with EITHER a unique Contract Type OR no Contract Type
  • A Definition with no Contract Type specified will cause an Approval record to be created for ANY CM/PB Contract Type
  • You are not allowed to have an active Department/Approval Type/Contract Type record and an active Department/Approval Type/No Contract Type as that is considered redundant and would result in duplicate Department Approvals

 

Each Time the Batch is ‘Accepted’ (RFP) or ‘Submitted’ (Renewal Batch), any existing Approvals in the workspace are inactivated.  New Definitions are retrieved based on the current state of the CM and Batch.  Since the Contract Type could change during a Reprocess (RFP) or at any stage in the Renewal process, it is critical that new Definitions are evaluated with each workflow pass.  This prevents Approvals that no longer apply to a client from being orphaned and left in the critical path.  Consider the following RFP scenario:

  • A new client is created with Contract Type = PEO
  • Two Underwriting Definitions exist for Contract Type = PEO:
    • Risk
    • Carrier
  • When the Batch is Accepted, two active Underwriting Approvals are generated:
    • Risk (Pending)
    • Carrier (Pending)
  • It is then decided to convert this client to PEO-Low Cost
  • The Batch must be Reprocessed as the Contract Type is currently locked
  • The two existing Approval records are set to Status = Reprocess, but they are still Active in the workspace
  • The Contract Type is changed to PEO-Low Cost
  • One Underwriting Definition exists for Contract Type = PEO-Low Cost
    • HR
  • When the Batch is Accepted, we must inactive the invalid Approvals ‘Risk’ and ‘Carrier’ and generate the valid Approval ‘HR’.  If this did not take place, three Approvals would be in the system that would have to be processed, even though two of them no longer apply to the business
  • The inactivated Approvals are not removed from the system, they are simply removed from the current workflow process.  Notes/Comments on those Approvals are still available.
  • If this PEO-Low Cost client is ever Reprocessed and the Contract Type is set back to PEO, the existing inactive Approvals ‘Risk’ and ‘Carrier’ will be recycled (re-activated and re-used), and the non-applicable Approval ‘HR’ will be inactivated for possible future recycling

 

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 clicked [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 described above.  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

 

Continuing the Approval Process after an Approval has been ‘Declined’

The Client Master Status will be ‘Prospect’ and the Pricing Batch Status will be ‘New’.  All Approvals will be in the state they appeared when the Approval was declined (e.g. Approved, Declined, Pending, or Waiting) and IsActive = True.  The Batch could then be ‘Submitted’.  At this point, the ‘Accept’ workflow will take effect. 

Since new Underwriting Definitions are retrieved for each pass through the Approvals process, any changes to the client information are re-evaluated and Approvals are fully synchronized to the business.  Contract Type, Comparison Batch conversion to RFP Batch, Approval Assigned To, are examples of changes that will have an impact on the types of Approvals that will be used.

 

 RETURN TO TOP

 

Submitting a Renewal Batch

After the RFP Batch has become ‘Activated’, the RFP batch is ‘retired’ (i.e. no further changes can be made) and Renewal Batches are in effect.  The Approval Process is similar to the RPF process, but with minor changes.  Note: for all actions, the Approval or Underwriting Definition Approval Type must be ‘Renewal’

  • ‘Submit’ the Renewal batch
    • The Renewal batch status is progressed to ‘Underwriting’
    • Any existing Approvals are set to ‘Reprocess’ [Db]
    • All existing Approvals are set to IsActive = False [Db]
    • Approval Dependencies are created [Db]
    • Underwriting Definitions are located
    • Underwriting Approval Records that exist and match an Underwriting Definition are set IsActive = True, Status = ‘Pending’ (or ‘Waiting’ if it is a dependent) [Db]
    • Underwriting Approval Records that do not match an Underwriting Definition are created [Pipeline] and [Clone Task]

 

  • ‘Approve’ an Approval
    • Similar to the RPF Approval ‘Approve’ process, but the Batch status is progressed to ‘Approved’ when all Approvals are ‘Approved’.

 

  • ‘Decline’ the Renewal batch
    • Individual Approval records cannot be Declined, the entire Batch must be Declined
    • When Declined, all active existing Approval records are set to Status = Reprocess [Db]

 

 Changing Contract Types

 Contract Type changes affect the types of Approvals that must be in place for this client.

  • RFP Batch, Client Master Contract Type Change

    • The Contract Type cannot be changed from the Client Master once the Contract Status = Submitted. The Batch will have to be Reprocessed to facilitate a Contract Type change
    • After ‘Reprocess’, all Approvals are set to Status = ‘Reprocess’ [Db].  Those Approvals that applied to the current Contract Type are left IsActive = True
    • While in ‘Prospect’ status, after the Contract Type change is saved from the Client Master, the Batch is saved [Pipeline] causing Pricing Batch business logic to execute.
    • As described in the ‘Accept’ process, Underwriting Definitions are re-evaluated based on the Contract Type.  New Approvals are generated as needed and existing Approvals which match the Contract Type (or have an empty Contract Type) are recycled.  The status of all Approvals are reset to ‘Pending’ or ‘Waiting’ (based on dependencies)
  • RFP Batch, Pricing Batch Contract Type Change
    • The Contract Type on the Pricing Batch is Read-Only for RFP batch types.  This will prevent Pricing Batch Contract Type changes from occurring from the Pricing Batch.  The deal will have to be ‘Reprocessed’ before the Contract Type can be changed (from the Client Master)
  • Renewal Batch
    • The Contract Type cannot be changed once the Batch Status = Activated
    • While the Batch Status = Underwriting, valid Approvals are in place.  If the Contract Type is changed at this point:
      • Those Approvals are inactivated and set Status = Reprocess [Db]
      • New Underwriting Definitions are retrieved based on the Contract Type and new Approval records are created and existing Approval records which match the Contract Type (or have an empty Contract Type) are recycled 

Client Master RPF Actions

The following RPF Actions affect Approvals.  It should be noted that once the RFP batch is ‘Accepted’, Approvals are recycled or created based on the criteria outlined above.

  • Decline
    • Sets Approval Status = Reprocess [Db]
    • Approval remains IsActive = True [Db]
  • ReActivate
    • Approval Status is not changed
    • Sets Approval IsActive = False [Db]

 

Renewal Batch Actions

The following Renewal Batch Actions are included to give the reader an understanding of the process as it applies to Approvals

  • Kill
    • No effect on Approvals
    • Approvals that were in place prior to ‘Kill’ are unchanged
    • When the Renewal Batch is Submitted, Approvals will be created or recycled as necessary
  • Clone
    • No effect on Approvals
    • Approvals that were in place prior to ‘Clone’ are unchanged and left attached to the Batch that was cloned
    • When the Cloned Renewal Batch is Submitted, Approvals will be inactivated, created or recycled as necessary

 

Comparison Batches

Approvals that are attached to the RFP Batch at the time of ‘Accept’ are the only Approvals that will need to be processed (Approved or Declined).  As the RFP Batch is ‘Reprocessed’, it is possible that a Comparison Batch could be converted to an RPF Batch.  A workspace could end up with many sets of Approval records attached to the various Batches that were cycled through the Comparison/RPF/Comparison conversion.  The following process is implemented during this conversion:

  • The current RPF Batch is changed to a Comparison Batch type [Db]
  • The current RPF Batch Approvals are set IsActive = False, Status = “”[Db]
  • Any existing Approvals which are attached to the Comparison Batch that will now become the RPF Batch are set IsActive = True, Status = “”[Db]
  • The Comparison Batch type is changed to RFP [Db]

As in other processes, the new RFP Batch can be ‘Submitted’, then ‘Accepted’, and the ‘Accepted’ process described above will be implemented.

 

 RETURN TO TOP

   

Approval State Diagrams

  

Sample Approval state progressions are shown in the following diagrams:

 


 

 

 

 

RETURN TO TOP

 

 

NOTICE: You are in the old ClientSpace Help system. Please link to the new ClientSpace Help here https://extranet.clientspace.net/helpdoc/home/ClientSpace.htm