How the Contract Compliance Checks Scheduled Job Works — Technical Deep Dive - Support and Troubleshooting

How the Contract Compliance Checks Scheduled Job Works — Technical Deep Dive Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Overview

The Contract Compliance Checks feature allows administrators to define condition-based rules that automatically update field values (such as Expiration) on contract records. A scheduled job runs nightly and evaluates these conditions against all contracts.

Tables Involved

Condition Check Definitions (clm_condition_check)

This is the parent configuration table. Each record defines what table to check, which field to update, and in what order. For example, a record might say "check the ast_contract table and update the Expiration field."

Key fields: Table, Condition field, Event name, Order

Condition Records (clm_condition_checker)

These are child records linked to a parent definition above. Each one defines a specific condition and the value to set when that condition is met. For example, "if the contract end date is between 91 and 181 days from now, set Expiration to Within 180 days."

Key fields: Name (the value to set), Expiration Condition (the filter that must match), Order, Event name

How the Evaluation Works

The scheduled job "Contract Compliance Checks" runs nightly and follows this flow:

The job loads all parent records from clm_condition_check , ordered by the Order field.

For each parent record, it loads all associated child conditions from clm_condition_checker , also ordered by their Order field.

Each contract record in the target table is evaluated against these child conditions one by one, in order.

The first condition that matches wins. The field value is set, and no further conditions for that field are evaluated for that contract. This is the most important behavior to understand — if a contract matches the very first condition, all remaining conditions are skipped for that record.

If the field value is already set to the correct value, no update is performed. This avoids unnecessary database writes.

If an Event name is configured, an event is fired only when the field value actually changes. This can be used to trigger email notifications.

Example: Expiration Field Evaluation

Note: The below is purely an example for illustration purposes and does not necessarily represent the out-of-box configuration.

If the following child conditions exist under the Expiration check, ordered as shown:

Order Name Condition Summary 10 Within 180 days End date between 91–181 days from now 40 (empty) End date is empty, or more than 90 days out, or cancelled 50 Expired End date has passed 100 Within 30 days End date within 30 days 200 Within 60 days End date between 31–60 days from now 300 Within 90 days End date between 61–90 days from now A contract with an end date 120 days from now would match "Within 180 days" at Order 10. The job sets the Expiration field and moves on. It does not evaluate the remaining conditions for that contract.

Batching

The job supports optional batch processing, controlled by two system properties:

contract_compliance_check_job.batching — Enables or disables batch mode contract_compliance_check_job.batchSize — Number of records per batch When batching is disabled, each contract is evaluated individually. When enabled, contracts are grouped into batches and evaluated together for better performance on large datasets. The first-match-wins behavior remains the same in both modes.

Scheduled Job Details

Name: Contract Compliance Checks Trigger: Daily (default midnight) Logging: Logs "Started Contract Compliance Checks job" at the start and "Completed Contract Compliance Checks job" on success. Errors are logged with the exception detail. Key Points

First match wins — The Order field on child condition records controls priority. The first matching condition is applied and all remaining conditions are skipped for that record and field. All conditions are evaluated dynamically — The job does not hardcode any specific condition names or values. Any active condition record linked to a parent check will be picked up automatically. No unnecessary updates — If the field already holds the correct value, the record is not updated. Events fire only on change — Notification events are triggered only when the field value actually changes, not on every job run.