Docs · Features
Content routing
Content routing is the set of rules that decide where an incoming submission lands and which engine translates it, matched by file extension and submitter department, so nobody has to sort inbound content by hand.
What it does#
A routing rule is a match-then-place instruction. Its match side is a file extension and a submitter department; its target side sets the project and, optionally, the engine a matching submission should use. Rules are tried in priority order, ascending, and the first active rule that matches wins: nothing after it is consulted, so ordering is how you resolve overlap between rules. An empty match field is a wildcard for that dimension, so a rule with no match fields at all is a catch-all at its priority.
When nothing matches, a submission falls to the submitter's department inbox, found or created automatically, so nothing is ever dropped. A rule model also carries subject, workflow, and language-set fields for future matching and targeting, but nothing consults them at run time yet, so they are refused when you try to author them today; any pre-existing rule that carries them keeps the data but is flagged inert in the rule list.
Getting started#
- List the current rules in priority order.
- Add a rule matching the content you want to steer, with a project and, if you want, an engine override.
- Toggle a rule off when you want to keep it but stop it firing, or delete it outright.
routing rule list
routing rule add --ext md,html --department Support --project 3 --provider claude --priority 50
routing rule toggle 5
routing rule delete 5 --yes
The same actions are available on the Routing page in the web UI.
Works with#
- Workflows: a rule's engine target picks which engine translates a matched submission.
- Documents: on upload, the routing decision places a submission in a matching rule's target project, or the department inbox, before the document pipeline takes over; on a translate request, a matching rule's engine override wins over the project default.
- Connectors: a connector places content by its own connection's configured project and does not consult routing rules; only content submitted directly is routed.
Current limits#
Routing rules take effect on the API upload and translate paths, and only there. Uploads made directly through the web UI or through an in-process CLI upload do not consult routing rules today; they place documents by an explicit project choice or the department inbox instead.
Subject matching, and steering a submission onto a specific workflow or language set, are reserved for a future version. The fields exist on a rule but are not consulted at run time, so authoring them is refused rather than accepted and silently ignored.
An explicit project named on the upload request always short-circuits the rules; routing only decides placement when the caller names no project.
An empty match field is a wildcard for that dimension, so a rule with no match fields at all matches every submission at its priority. That makes a useful catch-all, but it is also easy to make too broad by accident.
Department budgets, per-project spend budgets, and language sets are independent, core features. They stay reachable even if content-routing rule authoring is switched off.