Preempted jobs

Although some PolicyCenter jobs start and finish quickly, other job take a long time to complete the entire lifecycle. Sometimes this delay is due to technical reasons such as contacting external systems. There may also be legal reasons such as legally-enforced delays during cancellation.

When jobs take a long time to complete, chances increase that multiple jobs started on the same branch and are in process at the same time. For instance, two jobs are based on exactly the same PolicyPeriod entity instance and its subobjects. When the first job finishes there is no problem. When later jobs started at the same time complete, there may be challenges binding the new changes. The job that finishes second does not have the changes recently made and bound by the job that finished first.

When two jobs run concurrently like this, this situation is called preemption when the second job to finish attempts to bind. When PolicyCenter tries to bind a preempted branch, initially the branch does not contain preempted changes. PolicyCenter must incorporate the changes from the preempting branch. Preemption applies to any PolicyCenter job, such as cancellation and reinstatement, not just policy change jobs. After the first job to finish is bound, any unfinished jobs are preempted. PolicyCenter attempts to fix these problems early, as soon as you view a preempted job rather than just waiting until the preempted job tries to bind.

For example, suppose on a personal auto policy, two users start policy change jobs at the same time:

  • One policy change adds an additional vehicle, effective March 1, keeping coverage amounts the same
  • One policy change increases the coverage amount on the original car, effective April 1. Remember that this policy was based on the original legally-enforced policy when the policy change started. PolicyCenter represents this policy change as a branch (a PolicyPeriod entity instance and its subobjects) that is a clone of the original branch before any of the recent changes.

PolicyCenter detects potential preemption when starting a job if it appears that another job is in progress. The second concurrent job displays a warning to the user.

This warning does not indicate that a preemption will necessarily occur, or that it already occurred. However, if both branches eventually bind, one of the two jobs will be preempted.

Despite this warning, PolicyCenter lets the user start the policy change job or another job anyway. The complexity of preemption really takes place when the jobs finish or you try to handle the preempted job. The first change to finish preempts (takes precedence over) any concurrent changes not yet finalized.

Note: The complexity of preemption occurs after the first branch is bound and the user tries to work with the preempted non-bound job. This can happen in any phase of the preempted job, not just in the bind phase. The finish time determines which branch needs special handling, not the start time of the two jobs.

For example, if the policy change that adds the additional vehicle finalizes first, PolicyCenter makes that branch the legally enforced branch for this period. Nothing very unusual happens from a database or user interface perspective as part of binding this job.

However, after the user binds this change, if there are open jobs on this policy, PolicyCenter displays a warning this job preempted another transaction. It offers a link to view that policy transaction immediately.

At this point in the application, it is possible that the user might withdraw or ignore other non-bound branches.

However, if any user attempts to bind the second change (the coverage increase change), that change was preempted. That change was originally based on a branch that is no longer the most recently bound branch. PolicyCenter displays special options to handle the preemption.

Let us first consider the case in which the job that you bound first in real-world time had an earlier effective date than the second-to-bind change. This is a standard preemption. Before binding the coverage increase change, PolicyCenter must add the additional vehicle to the draft branch containing the coverage increase before attempting to bind the increased coverage.

Note: PolicyCenter must merge changes like this during preemption. Otherwise, when you bind the coverage change, the additional vehicle would be missing. It would appear as if you removed the vehicle from the policy as of April 1 as part of the recent change even though that was not your intention.

If you later view the preempted job, PolicyCenter warns you with a message at the top of the window. Also, the Handle Preemption button appears if you have preemptions to handle on this job.

You must choose to do one of the following:

  • Click Handle Preemption to merge changes as appropriate from recently-bound jobs into the active job that is about to be bound.
  • Click Withdraw to withdraw (abort) the current job.

If you click Handle Preemption to handle the preemption, PolicyCenter displays a tree showing the preemptions.

You can use the tree navigation (clicking on - and + signs) to hide or show parts of items in the hierarchy.

Use the buttons the screen to choose among the following actions:

  • Click the Apply All Changes button to apply all changes.
  • Click the Withdraw button to withdraw the job.
  • Click the Decide Later button to save the draft and return to the policy review screen.

Effective date later

If you apply changes and the effective date of your draft branch is later than effective dates of other bound jobs for that period, PolicyCenter simply applies the changes. This is a standard preemption.

Effective date earlier

However, if the effective date of your draft branch is earlier than effective dates of any bound jobs for that period, this preempted job is also out of sequence. Because it is out of sequence, there might be out-of-sequence merge conflicts. If there are merge conflicts, they appear in the Change Conflicts tab. You can review each conflict and determine whether to merge each change forward. For more information about the meaning of out-of-sequence in PolicyCenter, see Out-of-sequence jobs.

Important: A job can be both preempted and out-of-sequence, depending on the effective date of the current branch compared to the effective date of other bound branches. If you apply changes to handle the preemption, there might be merge conflicts. If this happens, PolicyCenter displays the same change conflicts user interface (the Change Conflicts tab) as a standard out-of-sequence job.

How PolicyCenter actually handles preemptions

In the PolicyCenter interface for preemption handling, it appears as if PolicyCenter simply merges changes into the latest selected (draft) branch. However, from a database perspective, PolicyCenter actually creates a new branch to handle the preemption.

The changes happen in the following order:

  1. PolicyCenter creates a new branch that is a copy of the most recently bound PolicyPeriod in that contractual period. By definition, this includes all changes from any preempting branch (or branches for multiple preemptions). This is the safest way to preserve consistency with a legally enforced branch.
  2. PolicyCenter then merges the changes you attempted to make in the preempted branch to this new branch.
    Important: In rare cases, PolicyCenter cannot automatically reapply the changes. This can happen if you make a change to a vehicle that has been removed in a preempting branch. Because of the preempting branch, there is no longer a vehicle in the newly merged branch. If such rare cases occur, after PolicyCenter reapplies changes, PolicyCenter opens a worksheet to notify you about change conflicts. This is just a notification. It requires no action.
  3. PolicyCenter discards the branch that the user was actively working on (the preempted branch) after handling the preemption. PolicyCenter replaces it with the new merged branch in the user interface and in the database.
  4. You can customize application logic that occurs after handling a preemption but before discarding the draft branch and binding the new PolicyPeriod. For more on this topic, see Policy period plugin.