How routing works
How a job group decides each document’s type — member priority, first-match-wins, and the health check.
When a mixed batch flows through a Job Group, the group has to decide which template owns each document. It does that with one simple rule applied in a deliberate order — and a read-only health check that catches the ordering mistakes before they cost you a run. This page explains the model so you can reason about why a document landed where it did.
The one rule: first match wins
A Job Group's member templates form a priority list. When a document comes in, the group offers it to the members from the top of the list down, and the first member whose splitting rule recognises the document claims it. As soon as one member claims a document, the search stops — lower members never even see it.
So order is not cosmetic; it is the routing logic. A member higher in the list always gets first refusal on every document. Reorder the members and you change which template wins a document that more than one member could have claimed.
Two consequences fall out of this directly, and they're worth holding in your head:
- A broad matcher placed high swallows documents meant for a more specific template below it. If a member near the top recognises almost anything — a catch-all — every document stops there, and the specific templates underneath it never fire.
- A specific matcher placed high is safe. Put the narrow, confident matchers near the top and the broad catch-all at the very bottom, and each document falls through to the most specific member that recognises it.
Screenshot
The Job Group designer Members tab — the member templates listed in priority order, with drag handles to reorder them. — shot job-groups-routing-01
You set this order on the Members tab of the Job Group designer by dragging members up and down. Position one is highest priority. See Build a job group for the full walkthrough.
When no member recognises a document
Not every document will match a member's splitting rule, and that's fine — Scanix Desktop never forces a document into the wrong template. A document that no member claims is set aside for review rather than guessed at.
Where it's set aside depends on how the group is configured:
- A group that routes with member templates collects the leftovers in an Unrecognized review pile.
- A group driven by an AI module uses an Unclassified review pile for documents it couldn't place.
Either way, the set-aside documents are surfaced after the run so you can look at them and link them to the right template by hand. Nothing is silently dropped or mislabelled.
AI as a fallback router
If you'd rather not leave unmatched documents for manual triage, a group can hand them to AI. The AI-classify unrecognized documents toggle on the Members tab does exactly this: when no member's splitting rule matches a document, the AI reads it and picks the best-matching member template for you — for example, deciding Invoice versus Receipt.
This is a fallback that runs after the priority list, not a replacement for it. Members with real splitting rules still claim their documents first by first-match-wins; only the documents that fall through reach the AI.
Uses AI tokens
AI-classify unrecognized documents spends AI tokens for each document it has to classify, on whichever engine you've configured. Leave it off to rely only on your configured matchers, or on for a hands-off batch where you'd rather the AI sort the stragglers than leave them for review. Cloud calls go straight from your machine to your own provider account — see the AI Services catalogue.
Jobs Matching: the health check
Ordering mistakes are quiet — a shadowed member doesn't throw an error, it just never claims anything, and you only notice when a document lands in the wrong pile. Jobs Matching is the tab that surfaces these mistakes before you run a batch.
It is a read-only health check. It inspects each member's splitting rule and the order they sit in, then reports what it finds. It does not change anything and it does not run your batch — you fix what it flags over on the Members tab (reorder) or in the Template Designer's Document Splitting section (change a matcher).
At the top, four tiles give you the shape of the group at a glance — Members, Clean, Warnings, and Errors — and a banner reads All members route cleanly when there's nothing to fix. Below that, group-level findings sit alongside a per-member breakdown.
What it checks
The check sorts members into four kinds, then looks for the collisions those kinds tend to cause.
Each member is labelled by what its matcher does:
| Kind | What it means for routing |
|---|---|
| Catch-all | Claims every document it's offered. Belongs at the bottom as a fallback — anywhere higher and it shadows everything below it. |
| Content matcher | Recognises documents by their content (for example, a barcode value). The healthy, specific case. |
| Separator-only | A blank-page or patch-code matcher. It marks where documents split but doesn't claim ownership of content — documents fall through to the next member. |
| Unwired matcher | A matcher type that isn't wired into group routing yet, so it never claims documents today (see the caveat below). |
From the kinds and their order, the check raises findings at three levels — info, warning, and error:
- Shadowed member — a catch-all sits above this member, so it can never see a document. Flagged as an error.
- No catch-all fallback — nothing at the bottom claims the leftovers, so unmatched documents will go to the review pile. Surfaced so you opt into that deliberately rather than discover it after a run.
- Duplicate matcher — two members share the same matcher value; the higher one always wins, and the lower one only ever claims what the first doesn't.
- Separator-only / unwired — a member that won't claim content documents on its own, in case you expected it to.
Screenshot
The Jobs Matching tab showing the four summary tiles (Members, Clean, Warnings, Errors), the “All members route cleanly” banner, and the per-member analysis grid. — shot job-groups-routing-02
The most common fix is simple: if Jobs Matching says every member is separator-only or unwired and nothing claims your documents, add a catch-all member at the bottom so there's always a fallback. If it flags a shadowed member, move the catch-all down below the specific templates.
Some matcher types aren’t wired into group routing yet
Not every splitting method participates in group routing today. Matcher types that aren't wired in yet are labelled Unwired matcher in Jobs Matching and never claim documents until that wiring ships, so don't rely on them as a member's only matcher. If you've built a group around one, give the member a matcher that's supported, or place a catch-all below it. The check exists precisely to make this visible before a run.
Putting it together
A well-ordered group reads top to bottom like a decision list: the most specific matcher you trust first, broader matchers below it, and a catch-all at the very bottom so nothing is ever lost. Jobs Matching confirms that shape is sound, and the Unrecognized or Unclassified review pile catches anything that still slips through — with AI-classify as an optional safety net for hands-off batches.
Next steps
Build a job group
Add member templates, set their priority order, and turn on AI-classify if you want it.
AI Services catalogue
How AI classifies documents and drives extraction when matchers aren’t enough.
Document splitting
Set the splitting rule on each member template that routing relies on.