Authoring a claim generation setup

A claim generation setup turns a class of transactions into claims on a schedule, entirely through configuration — no code per claim type. This page walks through authoring one safely. The concepts behind each element are covered in Trade claims; the entity-level field reference is under Claim Generation Setup and Claim Settlement Setup.

Setups live in the Claims app under Claim Generation Setups (/ClaimGenerationSetup). A setup record has two tabs: Rules, which holds the setup's Claim Generation Rule rows (see Selection rules), and Details, where every pipeline field sits in five collapsible sections. You need create and edit permission on both entities (both belong to the Claims product licence), and access to Setup → Platform → Monitoring → Jobs to read run results, because generation always runs as a background job. You do not have to start from a blank setup: xMatix can create five ready-made setups for you (see The five shipped setups).

Saving a setup that names a Source Entity compiles and executes the main source query with a one-row limit, so a bad field path or filter expression fails at save time. The netting query gets the same probe only when both Netting Source Entity and Netting Filter Expression are present. This is a structural check, not a financial reconciliation of the whole population. A setup with a custom Target Entity and no Processed Flag Field is refused outright.

A newly created setup defaults to Active off and Simulate Mode on. A setup copied from another can carry any persisted values, including active and non-simulated, so inspect the exact row instead of assuming a state from its name.

Procedure

New Claim Generation Setup form with Document Number, Claim Type, Source Entity, Grouping Fields, Schedule Group, Run Order, Batch Size, Aggregate Function, Active and Simulate Mode — The create form asks only for the identity, source, grouping and scheduling of the setup; selection rules, mappings and netting are completed afterwards on the Details and Rules tabs. A new setup starts with Active off and Simulate Mode on.UI captured 2026-09-05

The create form asks only for the identity, source, grouping and scheduling fields; everything else is completed on the Details and Rules tabs after the first save. Keep Active off and Simulate Mode on until a full simulated cycle reconciles independently.

Step 1 — Create the setup and name its source

Choose New on the Claim Generation Setups list. Give the setup a Document Number (its name), a Claim Type and the Source Entity whose records earn the claim — scheme ledger accruals, invoice lines, credit-note lines, goods-receipt lines, purchase-order lines or any entity including custom ones. Choose the source before Grouping Fields, because that list is built from the source entity's fields.

The claim type is normally fixed from the setup. Claim Type Source set to SourceField:<path> (on Details after the first save) reads it per source row instead, falling back to the setup's Claim Type when the path is empty; if both resolve to nothing the run fails. The setup's Claim Type picklist is the generation engine's coded vocabulary and must equal the Claim Type of the settlement setup that will settle the claims.

Assign a Schedule Group with a Run Order (default 100). The shipped groups are Nightly, Weekly and Monthly (Day 1); organizations can add their own picklist values. A setup with no schedule group can still be run manually but never runs on a schedule. Batch Size (default 200, clamped to 1–5000 at run time) is the number of source rows read per page; it affects memory and progress reporting, not the result. Save.

Step 2 — Define selection

Open the Details tab, section Source & Selection, and the Rules tab. Restrict the source three ways, all optional but usually combined:

Rule rows on the Rules tab — Sequence, Field Name, Operation and Field Value. Operations are Equals, Not Equal, Greater Than, Less Than, Contains, In and Not In. Rule Success Criteria combines the rows with AND (also used when it is empty) or OR; Rule Custom Logic such as (1 AND 2) OR NOT 3 overrides the criteria and references sequence numbers. A formula that names a sequence with no rule row, or contains an unknown word, fails the run rather than being ignored; a rule row with a blank Field Name is silently dropped, which is the usual way a formula ends up pointing at a missing sequence. How to add, change and test rules is under Selection rules.
Filter Expression — a dynamic-LINQ predicate for conditions rules cannot express, for example Quantity > 0. It is ANDed with the rule rows, never a replacement for them.
Date Window (None, Last Month, This Month, Last N Days with Date Window Days) applied to Date Field, which may be a navigation path such as a line's parent document date. Windows are resolved from the UTC date; Last N Days runs from N days ago up to and including today. None disables date filtering whatever the field says, and a window with a blank Date Field is silently inert.

Name the Processed Flag Field (section Mappings & Output) when the source has a suitable Boolean field. The query then excludes flagged rows, and a successful claim write flags its contributors in the same transaction. For a normal Claim target this flag is optional because Claim also has a generation-key guard; without it the source is read again on every run even though an identical key is skipped. For a custom Target Entity the flag is mandatory.

Step 3 — Choose grouping and aggregation

In Grouping & Amount, Grouping Fields is a comma-separated list of field paths whose joined values form each claim's group key — one claim per distinct combination, typically partner, branch and scheme, or supplier and item. It is mandatory: the run fails on the first source row it meets without it (a source that returns no rows completes quietly). Set Partner Account Path and Branch Path when the partner and branch are not direct PartnerAccountId/BranchId columns on the source row; the generated claim's Partner Account and Branch come from these paths.

Then choose the Aggregate Function. Sum accumulates Amount Field across the group into one claim line (quantity 1), optionally transforming each contribution through Amount Formula, where the raw value is available as amount and the source row's own fields are in scope. Per Record maps one claim line per source row. Sum configured without an amount field fails the run.

Step 4 — Map the claim

Header Mapping and Line Mapping (section Mappings & Output) are JSON objects that map target field names to source paths or tokens. A plain value is read as a navigation path on the source row; the tokens are @Item:<item name> (look up an item by name), @const:<value> (a literal), @amount (the aggregated amount), @parent (the id of the claim header being written) and @format:{Path}-{Other.Path} (interpolate several paths into one string). A target field name that does not exist on the claim is stored in the record's custom-field bag rather than rejected, so check spellings. Header mapping is evaluated once from the first row that opens each group, before any amounts have been accumulated — keep it to values that are constant within the group key and do not use @amount there.

Set Owner Resolution: None, Resource User (the user behind the active field-sales resource of the claim's partner, matched on branch when the resource has a default branch) or Branch Owner (the branch's owner). An unmatched owner leaves the claim unowned rather than failing. Supplier Account is the party the claims are raised on; batching later skips claims that have none.

Step 5 — Add netting, if the claim type needs it

The Netting Leg section subtracts a second source's total per group before the claim is written — sale returns against a discount computation, payouts already made against a fresh calculation. Set Netting Source Entity and Netting Amount Field (mandatory once a source is named — the run fails rather than netting zero), and optionally Netting Filter Expression, Netting Partner Path, Netting Branch Path (both default to PartnerAccountId/BranchId), Netting Date Field and Netting Date Window. The netting window has no day count of its own, so Last N Days on the netting leg means today only. Netting reduces the first claim line, so it is meaningful for Sum setups; groups that net to zero or below produce no claim. Because save probes the netting query only when both its source entity and filter expression are present, a successful save does not prove a partially configured netting leg can run.

Step 6 — Configure settlement for the claim type

Under Claim Settlement Setups, create or review the active setup for this claim type; the settlement job picks the active setup whose Claim Type equals the claim's type exactly. Settlement Document decides what an approved claim produces: CreditNote (default), Invoice (bill the counterparty from the approved values) or None (nothing is created; only the configured event is raised). The list also offers Adjustment (Part to Part), but the settle job does not recognise that value and fails. Apply To Open Invoices knocks a credit note off against the supplier account's open invoices oldest-first; Auto GL Posting is copied onto the created document, which is still created as Draft; Raise Event Name publishes a business-rule event after settlement, best-effort. Header Mapping and Line Mapping shape the document with the tokens @approvedAmount, @approvedQuantity and @const:<value>.

The generation setup's Claim Type must also exist in the settlement setup's own Claim Type list; Warranty Repairs, for example, is offered here but not there. Settlement Grouping settles per claim unless it is set to PerBatch — the list's Per Batch (consolidated) value is not recognised. Keep the settlement setup in Simulate Mode until approved quantities and mapped output agree with an independent calculation. In simulate mode the settle job reports the document it would have created and leaves the claim unsettled. Every settlement field, and how to settle claims approved during simulation, is on Claim settlement setups.

Step 7 — Run in simulate mode and read the job result

Run the setup with its Generate Claims action while it is still in simulate mode. The action does not generate inline: it enqueues a background run scoped to this one setup and returns the job run id, so open Setup → Platform → Monitoring → Jobs to read the outcome. The enqueue key is bucketed to the minute, so a double-click collapses into one run while a deliberate re-run a minute later goes through. The run summary reports, per setup, claims written, lines written and candidates skipped, and for a simulated run the number of candidates with a preview of the first few groups and amounts — without creating anything or flagging any source row. Auto-submit is skipped entirely in simulate mode. Compare a full cycle against the process being replaced and investigate every difference until it has an explanation.

Step 8 — Activate

Switch Simulate Mode off and mark the setup Active only when it should join scheduled group runs. A schedule-group run selects the active setups of its group and executes them in ascending Run Order; the manual Generate Claims action runs the selected setup regardless of its Active flag and ignores Run Order. The schedule itself is a job schedule: create one per schedule group on the Schedules tab of Setup → Platform → Monitoring → Jobs for the Generate claims job with the group's stored value in the payload (for example {"scheduleGroup":"MonthlyD1"}) — no schedule is shipped. Optionally enable Auto Submit For Approval: each newly written claim is submitted to its approval process straight after the run, and submission failures (no process configured, already pending) are written to the application log without failing generation.

Expected result

Saving the setup proves the main query can return at most one sampled row without a compilation or runtime error; it does not prove the complete population or every optional netting configuration. A simulated run reports the candidate groups, lines and amounts in the job summary without creating target records or changing processed flags. After activation, the schedule creates normal claims in Draft status per eligible key and flags sources when configured. For a custom target, verify target and source state before every retry because header, lines and flags are not written in one transaction.

Verify the saved setup

Details tab of a saved claim generation setup showing the Source & Selection, Grouping & Amount and Mappings & Output sections with their persisted values, and the Generate Claims action in the header — After saving, the Details tab exposes the whole pipeline in collapsible sections. Re-read each persisted value against the reviewed design: the save-time probe only proves the source query compiles and runs, not that the selection, grouping or mappings mean what you intended.UI captured 2026-09-05

The Details tab exposes every part of the pipeline in five collapsible sections: Source & Selection, Grouping & Amount, Mappings & Output, Netting Leg and Scheduling & Execution (Schedule Group, Run Order, Batch Size, Strategy Key, Active, Simulate Mode). Re-open each section after save and compare the persisted fields with the reviewed design; a successful query probe does not validate business meaning.

Rules tab of a claim generation setup listing two rule rows with Document Number, Claim Generation Setup, Sequence, Field Name, Operation and Field Value columns, a delete button on each row and a New button above the list

The Rules tab is the child rule list combined by Rule Success Criteria or the custom logic formula. Confirm Sequence, Field Name, Operation and Field Value for every row. When a filter expression is also present, it is combined with these rows rather than replacing them. The screenshot comes from an older configuration: its Operation values (equal, notEqual) are not the values the Operation list offers today, and equal would make the run fail — check that every rule's Operation is one of the seven listed under Rule fields.

Fields

The fields of a setup, in the order the Details tab shows them. Document Number appears only on the create form. The create form also carries Claim Type, Source Entity, Grouping Fields, Schedule Group, Run Order, Batch Size, Aggregate Function, Active and Simulate Mode. Field paths are internal field names, and dots walk to related records.

Field	What it means	Notes
Document Number	The setup's name, shown in job progress and run summaries	Required. Typed by you; setups have no numbering series
Source Entity	The entity whose records earn the claim	Required. Any entity, including custom ones. Choose it before Grouping Fields
Claim Type	The type stamped on every generated claim	Required. Must match the Claim Type of the settlement setup that settles these claims
Claim Type Source	Where the claim type comes from	Blank uses Claim Type. `SourceField:<path>` reads it from each source record and falls back to Claim Type when that path is empty
Filter Expression	An extra condition written as an expression	Always added to the rules with AND. Tested on save
Rule Success Criteria	How the Rules rows combine	`AND` (default) or `OR`. Ignored when Rule Custom Logic is filled in
Rule Custom Logic	A formula over rule sequence numbers, such as `(1 AND 2) OR 3`	Only sequence numbers, AND, OR, NOT and brackets are allowed
Date Field	The source date the window is measured against	Has no effect while Date Window is None
Date Window	Restricts the source to a period	`None` (default), `Last Month`, `This Month`, `Last N Days`. Worked out from the run's UTC date
Date Window Days	The N for `Last N Days`	A negative or empty value means today only
Grouping Fields	Comma-separated field paths; each distinct combination becomes one claim	Required. A run fails without it as soon as it meets a source record
Partner Account Path	Where the claim's partner account is read	Blank reads the source's own partner account field
Branch Path	Where the claim's branch is read	Blank reads the source's own branch field
Amount Field	The number summed into the claim	Needed for Sum, otherwise the run fails
Aggregate Function	How source records become claim lines	`Sum` (default): one line per claim, quantity 1. `Per Record`: one line per source record
Amount Formula	An optional expression applied to each record's amount before it is summed	`amount` is the raw value, and the source record's fields are in scope
Line Mapping	JSON that maps claim line fields to source paths or tokens	Tokens are listed in Step 4
Header Mapping	JSON that maps claim header fields	Evaluated once, from the first record in each group
Processed Flag Field	A Yes/No field on the source that marks a record as already claimed	Records already flagged are skipped, and claimed records are flagged. Required when Target Entity is set
Supplier Account	The party the claims are raised on	The same for every claim from this setup. Batching skips claims without one
Owner Resolution	Who owns each generated claim	`None` (default), `Resource User`, `Branch Owner`. If no match is found, the claim has no owner
Auto Submit For Approval	Submits each new claim for approval after a real run	Off by default. Skipped in simulate mode
Target Entity	Writes a different document type instead of a claim	Leave it blank for claims
Target Line Entity	The line type written under Target Entity	Blank writes header-only documents
Netting Source Entity	A second source whose total is subtracted from each claim	Turns netting on
Netting Filter Expression	Narrows the netting source	Tested on save only when Netting Source Entity is set too
Netting Amount Field	The number summed on the netting source	Required once Netting Source Entity is set
Netting Date Field	The netting source date the netting window is measured against	Has no effect while Netting Date Window is None
Netting Date Window	Restricts the netting source to a period	`None`, `Last Month`, `This Month`, `Last N Days`. Measured from the run date, not from the claim's own records. `Last N Days` means today only, because netting has no day count
Netting Partner Path	The netting source field matched against the claim's partner account	Blank uses the netting source's own partner account field
Netting Branch Path	The netting source field matched against the claim's branch	Blank uses the netting source's own branch field
Schedule Group	The scheduled batch the setup belongs to	`Nightly`, `Weekly` or `Monthly (Day 1)`, stored as `Nightly`, `Weekly`, `MonthlyD1`. Blank means it is never scheduled
Run Order	The setup's position within its schedule group	Required. Default 100. Lower runs first
Batch Size	How many source records are read per page	Default 200, held between 1 and 5000 at run time
Strategy Key	Selects a different collection method	Leave blank. No other method is installed, so any value makes the run fail
Active	Whether scheduled runs include the setup	Off by default. Generate Claims runs the setup either way
Simulate Mode	Report only: no claims are written and no records are flagged	On by default

Full type and requiredness details are in the Claim Generation Setup reference.

Selection rules

A Claim Generation Rule is one condition that a source record must meet to earn a claim — for example "the invoice is Posted" or "the damaged quantity is greater than 0". A setup can have any number of rules. When the setup runs, xMatix turns all of its rules into a single condition on the source entity, adds the Filter Expression and the date window, and reads only the records that pass. Rules are the easiest way to narrow a setup, because each one is a plain field, operation and value rather than an expression.

Step 1 — Add a rule

Open the setup and select the Rules tab. Select New above the list. The form asks for:

Document Number — the form requires something here, but the number you type is replaced on save by the next number from the rule numbering series (CGR-…). Type any placeholder, such as 1.
Claim Generation Setup — already filled in with the setup you opened it from. Leave it.
Sequence — a unique number for this rule (1, 2, 3 …). It is the number a Rule Custom Logic formula uses to refer to the rule.
Field Name, Operation, Field Value — the condition itself (see Rule fields).

Save. The rule appears in the Rules list with its CGR number.

Step 2 — Change a rule

The rows of the Rules list have only a delete button. To change a rule, select its Document Number in the list. The rule's own page opens; select the pencil next to a field to change it in place, then save. You can also move a rule to another setup there by changing Claim Generation Setup.

Step 3 — Remove a rule

Select the delete button on the rule's row in the Rules list (or Delete on the rule's own page) and confirm. If the setup has a Rule Custom Logic formula that mentions the rule's sequence number, edit the formula in the same sitting — otherwise the next run fails because the formula points at a rule that no longer exists.

Step 4 — Test the rules

Saving a rule does not test it. Switch the setup to Simulate Mode (if it is not already), run Generate Claims, and read the result in Setup → Platform → Monitoring → Jobs. A failed run names the problem, for example an unknown operation or a sequence number missing from the formula. A run that succeeds but reports no candidates usually means a rule value does not match the stored values (see Common problems).

Rule fields

Field	What it means	Notes
Document Number	The rule's number	Required on the form, but replaced on save by the next number from the Claim Generation Rule Settings series (prefix CGR)
Claim Generation Setup	The setup the rule belongs to	Required. Filled in when you add the rule from the setup's Rules tab
Sequence	Orders the rules and identifies the rule in a Rule Custom Logic formula	Empty counts as 0. Use a different number for each rule: with a formula, only one of two rules sharing a number is used; with AND/OR both are
Field Name	The field on the setup's Source Entity that is tested	Use the field's internal name (for example `DamagedQuantity`), not its label. Dots walk to related records: `Invoice.Status`, `ServiceOrder.BranchId`, `GoodsReceipt.SupplierAccountId`. A rule with an empty Field Name is ignored. A name that does not exist on the source fails the run
Operation	How the field is compared with the value	One of Equals, Not Equal, Greater Than, Less Than, Contains, In, Not In. Empty means Equals. Contains matches part of a text field. In and Not In take a comma-separated list in Field Value
Field Value	The value to compare with	Leave empty, or type `null`, to test for an empty field (`Not Equal` + empty means "has a value"). `true`/`false`, numbers and IDs are compared as those types, so the field must be of the same type. Everything else is compared as text. Picklist fields hold the value's internal name, which can differ from its on-screen label

How rules are combined

No formula, Rule Success Criteria AND (or empty). A record must pass every rule.
No formula, Rule Success Criteria OR. A record must pass at least one rule.
A Rule Custom Logic formula. The formula decides, and Rule Success Criteria is ignored. Write sequence numbers, AND, OR, NOT and brackets — for example (1 AND 2) OR NOT 3. Words are not case-sensitive. Any other word fails the run, and so does a number that no rule carries. A rule that the formula does not mention plays no part.
Filter Expression. If the setup also has one, a record must pass both the rules and the expression.
Order. Rules are evaluated together, so the order of the Sequence numbers does not change the result; it only matters for the formula.

The five shipped setups

xMatix can create five ready-made setups, each with its own rules. Nothing is created until an administrator turns on Seed the default claim generation setups under Setup → Feature Hub → Modules → Claims → Settings (group General; off by default). Saving the setting with the switch on creates whatever is missing straight away.

Setup	Claim Type	Source Entity	Rules (all combined with AND)
Scheme Claim (Invoice)	Scheme	Invoice Line	`SchemeDiscountAmount` Greater Than 0 · `IsClaimed` Not Equal true · `Invoice.Status` Equals Posted · `Invoice.PartnerAccountId` Not Equal null
Damaged Claim (Goods Receipt)	Damaged	Goods Receipt Line	`DamagedQuantity` Greater Than 0 · `UnitCost` Greater Than 0 · `IsClaimed` Not Equal true · `GoodsReceipt.SupplierAccountId` Not Equal null
Service Claim (Service Order)	Service	Service Order Line	`PostingType` In Generate Claims,Auto Generate Claims · `PackageClassification` Not Equal Packaged Item · `ClaimableQuantity` Greater Than 0 · `ItemServiceContractId` Not Equal null · `IsClaimed` Not Equal true · `ServiceOrder.PartnerAccountId` Not Equal null · `ServiceOrder.BranchId` Not Equal null
Expense Claim (Service Order)	Expense	Service Order Line	`PostingType` Equals Expense · `ClaimableQuantity` Greater Than 0 · `IsClaimed` Not Equal true · `ServiceOrder.PartnerAccountId` Not Equal null
Warranty Claim (Service Order)	Warranty	Service Order Line	`PostingType` In Generate Claims,Auto Generate Claims · `AssetServiceContractId` Not Equal null · `ClaimableQuantity` Greater Than 0 · `IsClaimed` Not Equal true · `ServiceOrder.PartnerAccountId` Not Equal null

All five arrive with Active off, Simulate Mode on, schedule group Nightly, Aggregate Function Per Record and Processed Flag Field IsClaimed. Things to know:

A setup is skipped when the organization already has a setup with the same name, or any setup with the same Claim Type and Source Entity.
Edits are never overwritten: seeding only adds setups that are missing.
Turning the switch off deletes nothing. A shipped setup you deleted is created again the next time the setting is saved with the switch on.
The Service and Warranty setups both read service order lines and are told apart only by which contract the line carries. If your lines can carry both, add a rule to one of them before you activate both.
Rule values such as Posted, Expense or Packaged Item must match the values your organization stores. Review them before you switch off simulate mode.

Example

A distributor wants damage claims only for receipts at its central warehouse branch. They seed the five shipped setups and open Damaged Claim (Goods Receipt).

On the Rules tab they see the four shipped rules (sequences 1–4).
They select New, type 1 as Document Number, set Sequence 5, Field Name GoodsReceipt.BranchId, Operation Equals and paste the branch's ID as Field Value, and save. The rule is numbered CGR-… automatically.
Rule Success Criteria is AND and there is no formula, so a receipt line now needs all five conditions.
With Simulate Mode still on they select Generate Claims and open Setup → Platform → Monitoring → Jobs. The run summary shows three candidate groups, all from the central branch.
They compare the three receipts with their own damage report, then switch off Simulate Mode and mark the setup Active.

Training

Practice exercise

In a sandbox, seed the shipped setups (or use any setup in simulate mode) and open Expense Claim (Service Order).

Add a rule with Sequence 5, Field Name ClaimableQuantity, Operation Less Than, Field Value 10.
Set Rule Custom Logic on the Details tab to 1 AND 2 AND 3 AND (4 OR 5) and save.
Run Generate Claims and read the job result.
Now delete the rule with Sequence 5 and run again without changing the formula.

Expected result: the first run succeeds in simulate mode and reports its candidates without creating claims. The second run fails, because the formula refers to rule 5, which no longer exists. Clear the formula (or remove OR 5) and the run succeeds again.

Quick reference

One rule = Field Name + Operation + Field Value; Sequence identifies it.
Field Name is the internal field name; use dots for related records (Invoice.Status).
Empty value or null tests for an empty field.
In / Not In take a comma-separated list.
AND is the default; OR or a Rule Custom Logic formula change that.
A formula must name only sequences that exist.
Rules are not tested on save — run in simulate mode.
Edit a rule from its own page (select its number); the list row only deletes.
Five ready-made setups: Feature Hub → Modules → Claims → Settings.

Permissions

To do this	You need
See, add, change or delete setups and rules	Access to the Claim Generation Setup and Claim Generation Rule entities in your security profile. The shipped Sales, Sales Executive, Sales Manager, Service, Standard User and System Admin profiles have full access to both
Run Generate Claims	The Generate Claims action grant on Claim Generation Setup. Of the shipped profiles, Sales Manager, Standard User and System Admin have it
Read run results	Access to Setup → Platform → Monitoring → Jobs
Turn on the shipped setups	Access to Setup → Feature Hub → Modules → Claims → Settings

For a user without the Generate Claims grant, the server refuses the action. Profiles are changed under Setup → Access Control → Security Profiles (see Security profiles).

Configuration

Setting	Where	What it affects
Seed the default claim generation setups	Setup → Feature Hub → Modules → Claims → Settings, group General	Off by default. Turning it on and saving creates the five shipped setups and their rules, inactive and in simulate mode. Turning it off deletes nothing
Rule numbering	Setup → Design Studio → Entities → Claim Generation Rule → Logic → Document Settings (Claim Generation Rule Settings)	The CGR series that numbers new rules. Changing the prefix or length affects new rules only
Rule Success Criteria, Rule Custom Logic, Filter Expression	The setup's Details tab, section Source & Selection	How the rules are combined, and the extra expression that is always added with AND
Operation values	Setup → Design Studio → Entities → Claim Generation Rule → field Operation	The seven shipped values are the only ones the engine understands. Do not add or rename values — any other value makes the run fail

Common problems

The run fails with "Unknown rule operation"

Cause: a rule's Operation holds a value the engine does not know — typically from an older configuration or an import, such as equal. Fix: open each rule and choose one of the seven values in the Operation list again, then run in simulate mode.

The run fails with "RuleSuccessCustomLogic references rule N, which does not exist"

Cause: the setup's Rule Custom Logic names a sequence number that no rule carries — the rule was deleted, renumbered, or has an empty Field Name (such rules are ignored). Fix: correct the formula or the rule's Sequence, or clear the formula to fall back to Rule Success Criteria.

The run fails with "Unknown token … in RuleSuccessCustomLogic"

Cause: the formula contains a word other than AND, OR or NOT (for example ANDNOT or a field name). Fix: use only sequence numbers, AND, OR, NOT and brackets.

The run fails and names a field

Cause: a rule's Field Name does not exist on the source entity (or a dotted path breaks), or the value's type does not suit the field — for example a number compared with a text field, or Contains used on a number field. Fix: check the field's internal name under Setup → Design Studio → Entities, and use a value of the field's own type.

The run fails with "No claim source strategy '…' is registered"

Cause: the setup's Strategy Key (section Scheduling & Execution) holds a value. Only the standard collection method is installed, and its key is blank. Fix: clear Strategy Key, save, and run again in simulate mode.

A scheduled run reports "No active setups for this trigger."

Cause: the schedule's payload names a group that no Active setup belongs to. The usual reasons are that the setup is still inactive, or that the payload uses the label Monthly (Day 1) where the stored value is MonthlyD1. Fix: mark the setup Active and put the stored group value in the schedule payload. A schedule with neither a group nor a setup in its payload fails with "Payload must carry setupId or scheduleGroup."

The run succeeds but finds nothing

Cause: usually a rule value that does not match the stored value. Picklists store the value's internal name, which can differ from the label you see, and text comparisons must match exactly. Fix: remove rules one at a time in simulate mode until candidates appear, then correct the value of the rule that removed them.

My OR formula picks up far too many records

Cause: AND is applied before OR, so 1 AND 2 OR 3 means (1 AND 2) OR 3 and a record meeting rule 3 alone passes. Fix: add brackets: 1 AND (2 OR 3).

Common questions

What happens if two setups could sweep the same source records?

When a processed flag is configured, a successful claim write commits the claim, lines and source flags together, and later queries skip those rows. Without a flag, both setups can read them; the Claim generation key only prevents a second claim with the same claim type, group and run month. Partition overlapping setups explicitly and do not assume one setup's key protects another claim type or grouping.

How is the period in the generation key derived?

From the month the run executes in (UTC), not from the date window or the source dates. The key is ClaimType|GroupKey|Period with the period as yyyy-MM, so a setup re-run next month for the same group produces a second claim unless a processed flag excludes the already-claimed rows. Within a month a rerun is skipped and counted as such.

Can a setup write something other than a claim?

Yes. Target Entity and Target Line Entity redirect the output to a different document type, including a custom entity, written through the metadata-driven data service. Its source Processed Flag Field is mandatory because custom targets have no generation-key guard, and simulate runs for such a target never report skips. The writer persists header, child lines and source flags through separate calls; if a failure occurs after header creation but before source flagging, a retry may create another header. Inspect and repair the partial result before rerunning.

How do I test changes to a live setup?

Switch it back to simulate mode and run Generate Claims, then compare the job summary before re-activating. The save-time dry run guards the query itself, but only a simulation shows you the groups and amounts.

Why does the claim type list differ from the one on a claim?

The generation setup, the claim and the settlement setup each have their own Claim Type picklist. Generated claims carry the generation setup's value verbatim, so a value that exists only here (such as Warranty Repairs) produces claims that no settlement setup can be created for until an administrator adds the same value to the settlement setup's list. What matters for settlement is that an active Claim Settlement Setup exists for exactly the value this setup stamps.