Split Appeals

What is Split Appeals

Split appeals was implemented under APPEALS-3419 and allows super users in the Clerk of the Board and SupervisorySeniorCouncil to split request issues off of an appeal. The resulting "split" creates 2 appeals: a new appeal with the selected request issues, and the original appeal with the remaining request issues.

Split Appeal Workflow

Accessing the Workflow

Split appeals is accessible to members of the Supervisory Senior Council and Clerk of the Board (permissions are located within User#can_split_appeal?). The workflow is accessed from the Case Distribution Page via the Correct issues link. Once on the Add/Remove issues page, the super user will be able to see a Split appeal button if:

1. There are multiple issues on the appeal.
2. The user is a member of the Supervisory Senior Council or Clerk of the Board
3. The split_appeal_workflow feature toggle is enabled.

The button can be clicked if the appeal:

1. Has 2 or more issues.
2. Has no issues being added/removed on the Add/Remove Issues page (issues "in flight" and not saved to the database)

Splitting an Appeal

Clicking the split appeals button routes the user to the split appeals workflow. The user is prompted to enter their split reason from a dropdown and select which issues they want to split. If the option other is selected, the user is prompted to fill out a reason. There are validations on the continue button (SplitButtons.jsx) that prevent the user from continuing if:

1. All fields are not filled out on the form.
2. All issues are selected to be removed from the appeal

The final step of the workflow is a confirmation page that shows the user the original appeal (with the issue(s) removed) and the new appeal that will be created. After clicking split appeal, the user is greeted with a success/fail banner on the Case Details page depending if the appeal was successfully split.

How the Split Works

Amoeba Gem

During the split process, data integrity is maintained from one appeal to another. To maintain these data relations, the split appeal process relies heavily on the Amoeba gem. When the split process is initiated in the workflow, the SplitAppealController is hit and the cloning process begins. Most of the split logic is handled by the amoeba_dup method. This method hits the amoeba block in the appeal model and recursively goes through each relation on the model in order to clone the existing data. There are 2 lambda functions that start and resolve the cloning process: the first lambda creates the appeal UUID and turns off rails validations so that the information can be cloned. The 2nd Lambda generates UUIDs for any supplemental claims that were generated from the cloning process.

Custom Amoeba Logic

After the amoeba_dup resolves, custom logic handles the more intricate data relations. The finalize_split_appeal method is responsible for handling all the custom logic like cloning the task tree, and cloning issues marked to be added to the new appeal.

Finalizing the Split

The end of the split process turns back on rails validation for the appeal, saves both the original and dup_appeal, creates a SplitAppealTask to serve as a note on the Case Timeline, and creates a SplitCorrelationTable record to document which issues were split. The SplitCorrelationTable tracks key information for the before/after issue(s) and appeals incase a rollback ever needs to happen (not implemented during this initial release).

Behind the scenes, the original issues on the appeal remain but are set to "on_hold" in the database. This status hides the cloned issues from being processed in Caseflow, but keeps the original issue still attached to the model. If the split were ever needed to be rolled back, the original issue would need their status changed to "in_progress" and the cloned issues could be deleted.