Delete or Invalidate Condition Records

When working with Condition Records in the Condition Record creation logic, you can delete or invalidate existing condition records directly from Groovy scripts so that outdated or superseded records no longer remain in the target Condition Record Set.

Note that the delete and invalidate operations are executed as part of Condition Record processing before the Condition Record splicing job runs and applies options such as withSplicingOption(), setSupersedingOn(), or attribute set / reset. This means that if there are already other Condition Records for the same keys, you need to consider how removing or invalidating specific records will affect the way splicing resolves the final non‑overlapping validity intervals.

Method Reference

To invalidate a Condition Record, use the method conditionRecordHelper.invalidate(Map recordData) in the in Groovy Condition Record creation logic:

• The method is callable only within the Condition Record creation logic.

• It takes the same input structure as conditionRecordHelper.addOrUpdate() — the values you provide are used to identify the existing Condition Record that should be deleted/invalidated.

• Identification of the target Condition Record is done using the full key set:
  keys + validity (validFrom, validTo) + conditionRecordSetId.

Execution Context and Configuration

• The delete/invalidate logic is exposed only via conditionRecordHelper inside the condition record creation logic.

• The actual behavior (delete vs. supersede/invalidate) is controlled by a splicing option at the job level:

  • The record is either deleted or superseded based on this configuration.

  • When the record is moved to the history table as part of this process, its status in the history table is set to invalidated.

• The delete/invalidation is executed before:

  • adding new records, and

  • applying other splicing operations.

Behavior and Error Handling

• If a matching condition record exists (based on keys + validity + CRS ID):

  • It is either deleted or superseded/invalidated, depending on the splicing configuration.

• If no matching record is found:

  • Nothing is changed; the process simply continues.

  • By design, no exception is thrown. Instead, a DEBUG-level log entry is written to the server log to indicate that the delete/invalidate operation was skipped.

• If any other issue occurs during processing, the behavior is the same:
  no exception is raised, and only a DEBUG log is written.

Usage Examples

Example data

Assume the following Condition Records exist in the target Condition Record Set (CRS):

Case 1 – Superseding Off

With superseding not turned on, the Groovy logic invalidates (deletes) a specific record:

conditionRecordHelper.invalidate([
    "key1"               : "Company 1",
    "validFrom"          : "2025-07-07",
    "validTo"            : "2025-07-30",
    "conditionRecordSetId": 7
])

Result: Only the older record remains in the condition record set:

The record identified by key1 = "Company 1", validFrom = 2025-07-07, validTo = 2025-07-30, conditionRecordSetId = 7 is deleted/invalidated.

Case 2 – Superseding On

When superseding is turned on, invalidation is handled through the splicing configuration. In the example below, validities are adjusted using shortenValidTo, and superseding is enabled via withSplicingOption().setSupersedingOn():

conditionRecordHelper.shortenValidTo([
    "key1"               : "Company 1",
    "validFrom"          : "2025-07-07",
    "validTo"            : "2025-07-16",
    "conditionRecordSetId": $crsId
])

conditionRecordHelper.withSplicingOption().setSupersedingOn()

Result: The original records are preserved or moved appropriately, and an additional history record is created to represent the invalidated period:

In this configuration, the affected record is superseded and stored in the history table with status invalidated, while the splicing logic ensures the resulting set of active records matches the desired validity pattern.