Reconnecting Cases After a Deleted and Recreated Parent

When a parent case (for example, a Company) is deleted and then recreated, it receives a new ref. Child cases (for example, Employee cases linked via company_ref) still hold the old ref. Those child cases must be updated so their reference field points to the new ref; otherwise the relationship is broken.

This page explains how to find the old and new refs, update the schema if needed, write an update script, and run it against the affected cases using a bucket.

Example: Company and Employee

  • Company has a unique reference field (e.g. company_ref) that identifies each company case.
  • Employee cases are linked to a company via a field such as company_ref.
  • When a company is deleted and recreated, the new company case gets a new company_ref.
  • Existing Employee cases still have the old company_ref and need to be updated to the new value.

The same pattern applies to any parent/child pair where the child stores the parent’s ref (e.g. Claim and Policy, Order and Customer).

Step 1: Find the Old Ref and the New Ref

Where refs are stored

Reference fields are often stored in a hidden fieldset called internal_references. If that fieldset is hidden from the UI, you may not see the ref when you open a case.

Make the ref visible (if needed)

To see the company’s ref so you can copy the new ref after recreating the company:

  1. Edit the Company case template schema.
  2. Ensure the field that holds the ref (e.g. company_ref) is included in a fieldset that appears in at least one view.
  3. If the ref lives in internal_references, add the internal_references fieldset to the relevant view(s) so the ref is visible on the case form or details screen.

Example: if your Company schema has:

fieldsets:
  - name: details
    fields:
      - name: company_name
        type: string
  - name: internal_references
    fields:
      - name: company_ref
        type: number
        sequence: true

then ensure the view used when opening a Company case includes the internal_references fieldset (or at least the company_ref field). After recreating the Company, open the new case and note the new company_ref.

The old ref is the value that still appears on the Employee cases you want to reconnect (e.g. in exports, in a bucket column, or via the API). If you no longer have it to hand, you can infer it from an Employee case that used to link to the deleted company (e.g. from a backup or from another system that stored it).

Step 2: Write a Script to Update the Ref

Write a script that:

  1. Receives the case payload (e.g. an Employee case).
  2. Sets the reference field to the new ref (replacing the old one).
  3. Returns the updated payload with exit(payload).

The reference field is often under internal_references. For example, if Employee has company_ref in internal_references:

// Replace OLD_COMPANY_REF and NEW_COMPANY_REF with your actual values
var OLD_REF = 12345;   // the ref that was on the deleted company
var NEW_REF = 67890;  // the ref on the recreated company

if (payload.internal_references && payload.internal_references.company_ref === OLD_REF) {
  payload.internal_references.company_ref = NEW_REF;
}

exit(payload);

If your ref is stored at a different path (e.g. a top-level company_ref), adjust the script accordingly:

if (payload.company_ref === OLD_REF) {
  payload.company_ref = NEW_REF;
}
exit(payload);

Create this script in the Script Editor, test it with a single case (using Input with a sample payload that has the old ref), then save and make it live. For running it on many cases, you will typically call it from a task that you run in batch on a bucket.

Step 3: Create a Bucket for Cases With the Old Ref

Create a bucket that returns only the child cases that still have the old ref:

  1. Go to the Case Template that holds the child cases (e.g. Employee).
  2. Create a new bucket (e.g. “Employees to reconnect to Company X”).
  3. In Criteria, add a condition so the reference field equals the old ref.

If the ref is in internal_references.company_ref, use a criterion that targets that path (the exact UI may show it as “Internal references → Company ref” or similar). Set it to equal the old ref value.

If your bucket uses an Advanced Query, you may need to query on the same path (e.g. internal_references.company_ref:<old_ref> or the equivalent for your query syntax).

Save the bucket. Open it and confirm it only lists the cases that should be updated.

Step 4: Run the Script on the Bucket

Use a task that runs your update script, then run that task in batch on the bucket:

  1. Create a task (or use an existing one) that executes your script — typically the task will receive the case as input and call the script, which updates the ref and exits with the modified payload so the case is saved with the new ref.
  2. Open the bucket you created (the one that filters by the old ref).
  3. Use the option to run the task in batch on the bucket (e.g. select all or a subset of cases and choose “Run task in batch” or equivalent). This runs the script once per case and updates each case’s ref to the new value.

After the batch run, the affected child cases will have their reference field set to the new ref and will again link correctly to the recreated parent case.

Summary

Step Action
1 Find the old ref (on affected child cases) and the new ref (on the recreated parent). If the ref is in internal_references, add that fieldset to the parent’s views so you can see the new ref.
2 Write a script that sets the reference field from the old ref to the new ref and call exit(payload). Test with one case, then save.
3 Create a bucket for the child case type where the reference field equals the old ref.
4 Run a task that invokes your script in batch on that bucket so every case in the bucket gets updated to the new ref.

This keeps parent/child relationships consistent when a parent case is deleted and recreated and its ref changes.

Copyright © 2025 Caseblocks Limited.