Fallback records

Fallback Records intercept the silent no-op when a definition's Context lookup finds no match. Configured per definition via the Fallbacks button. Multi-level for progressively-failing matches.

The conceptual treatment is on Fallback records (Concepts). This page covers the configuration UI and the practical decisions.

Where to configure

Open a definition and click the Fallbacks button on its card. The Manage Fallbacks modal opens with one section per level.

The number of levels depends on the definition's Context column count:

• 1 Context column → Level 0 only.
• 2 Context columns → Levels 0 and 1.
• 3 Context columns → Levels 0, 1, and 2.
• N Context columns → Levels 0 through N+1.

What each level does

For a definition with three Context columns, the levels intercept progressively-failing matches:

Level	When it fires
Level 0	First Context column doesn't match any row at all.
Level 1	First Context column matches some rows; second column narrows further but doesn't match.
Level 2	First two columns match some rows; third column narrows further but doesn't match.
Level 3	All three columns match but no row exists (technically the deepest possible no-match for this Context shape).

Each level can be configured independently. Levels you leave unconfigured fall through to the next level.

Configuring a level

For each level, pick a substitute row from the entity. The picker shows existing rows; you select the one to use as the fallback.

When the level fires, the engine uses that row as if it had matched — Mapped columns write its values to document fields, Dropdown columns rebuild option lists from it, etc.

Use a sentinel row

A common pattern: add a row to the entity specifically for fallback use. Name conventions help — e.g., vendorId="UNKNOWN", vendorName="—Unknown Vendor—", other columns left empty (or filled with conservative defaults).

The empty-cell rule still applies to fallback rows. So an "Unknown" / "—Unknown Vendor—" / (empty) row writes the name and leaves other fields alone.

Designing fallback granularity

The decision is: how granular do your fallback rows need to be?

Simple: one Level-0 fallback

Pick one substitute row for "anything that doesn't match." Covers every non-match case. Simple to maintain.

Works when:

• The fallback row is generic enough to make sense in any non-match.
• The reviewer noticing the fallback is sufficient response.

Per-level fallbacks

Pick different substitute rows for different no-match scenarios.

Example for a (customerInitials, vendorAccount, productCode) definition:

• Level 0 — customerInitials didn't match. A "customer not recognized" sentinel row.
• Level 1 — customer matched but vendor didn't. A "vendor not in catalog for this customer" row.
• Level 2 — customer and vendor matched but product didn't. A "product unknown" row.

The reviewer can tell from the populated values which kind of mismatch happened. More setup, more diagnostic value.

Per-discriminator-cluster fallbacks

For discriminator-pattern projects, you can use Context-aware fallback designs:

• Per-customer fallback rows. One sentinel row per customer.
• The Level-0 fallback fires only when the customer itself doesn't match (rare). Subsequent levels fire for missing vendor/product/etc., and the substitute row is customer-specific.

This requires more configuration but gives reviewers customer-specific defaults when narrower lookups fail.

When fallbacks aren't the right choice

Don't configure fallbacks reflexively. Several scenarios where silent no-ops are better:

• The reviewer should notice and act. A missing vendor in the Vendors entity is a real signal that the reviewer should add the vendor. A fallback hides this — the document populates with the fallback values and the missing-vendor problem doesn't surface.
• The downstream impact is mild. If a missing GL code just shows as —Not set— on a non-mandatory field, the silent no-op is fine. The reviewer can fix it manually without an automated fallback.
• The fallback row would be misleading. A fallback that writes "Unknown" everywhere risks letting bad data flow downstream. Better to block the document until the reviewer fixes the actual lookup.

The general principle: configure fallbacks when a default is genuinely better than a missing value. When the missing value is a real signal, let it stay missing so someone takes notice.

Behavior nuances

Behavior described from UI labels

The end-to-end behavior of multi-level fallbacks across all level configurations is documented from the UI labels in the Manage Fallbacks modal. The exact runtime semantics at each level may have nuances not fully verified through behavioral probing.

For high-stakes fallback configurations (compliance-relevant routing, audit-critical workflows), test the fallback behavior on a sample document before relying on it in production.

Fallbacks and cascades

Fallbacks fire on individual definition invocations. They don't affect the cascade structure:

• If a step's lookup fails and a Fallback fires, the step's writes happen using the fallback row's values.
• The next step in the cascade sees those writes.
• The cascade continues as if the matched row was the fallback row.

So fallbacks "rescue" individual steps from being silent no-ops, allowing the cascade to keep flowing rather than stalling.

Removing fallbacks

To remove a fallback level's configuration, open the Manage Fallbacks modal and clear the row pick at that level. The level becomes unconfigured; the silent no-op behavior returns for that scenario.

What's next

• Fallback records (Concepts) — the conceptual treatment.
• Context columns — the lookup key that determines which level fires.
• The empty-cell rule — important for understanding what fallback rows write.
• Definitions overview — back to the umbrella page.