How to automate business rules and routing decisions

What matters here

• Write the rules as a table, not as conditions inside the workflow. A table can be read, changed and checked.
• Give the table an owner. The person who answers for the outcome should be able to change the rule.
• Decide from facts the workflow gathered, not from what the requester typed.
• Use AI to sort free text into a category, then let the rules decide. Don't let a model make the decision itself.
• Send anything that matches no rule to a person. A default route hides the cases the rules missed.
• Record which rule decided each case, so every outcome can be explained.

Who this is for

You own a process in revenue operations, finance or support. The rules for who gets what, and when, live in a spreadsheet, a few workflow conditions and the heads of two senior people.

How it works in practice

What has to happen between the facts being gathered and the case going down the right route.

1. 1

   The facts are collected in one place

   Amount, customer tier, contract terms, region, history: everything the rules need, read from the systems that hold it.

2. 2

   Free text is sorted into a category

   An AI step reads the request and names the category and its confidence, so the rules have something to match.

3. 3

   The rules table is checked in order

   The first rule that matches decides the route: approve automatically, send for approval, or hand to a team.

4. 4

   Cases no rule matches go to a person

   With the facts and the reason no rule applied, so they can decide and suggest a new rule.

5. 5

   The decision is recorded with its rule

   Which rule fired, on which facts, so the outcome can be explained later.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Write the rules as a table

   A rule nobody can read is a rule nobody can change.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Zendesk, Salesforce,
   Stripe and Google Sheets, or whatever we run in those seats.
   
   Build a rules table with one row per rule: the conditions (amount
   band, customer tier, request category, region), the route (approve
   automatically, send for approval, hand to a team) and a priority.
   Keep it in a sheet the process owner can edit, and log every change
   with who made it and when.
   
   Rules are checked in priority order and the first match wins. Two
   rules that both match at the same priority is an error to report,
   not a tie to break at random.

2. 2

   Gather the facts before deciding

   Rules are only as good as the values they run on.

   Headless skills build-workflow tray-patterns

   Copy

   Use build-workflow. Before checking the rules, read every value they
   need from the system that holds it: the customer tier and contract
   from Salesforce, the payment from Stripe, the request from Zendesk.
   
   If a value a rule needs is missing, don't treat it as zero or as
   false. Send the case to a person and say which value was missing.

3. 3

   Sort free text with AI, then let the rules decide

   A model is good at reading and bad at being accountable.

   Copy

   Add an AI step that reads the request text and returns one category
   from a fixed list, with a confidence score and a one-line reason.
   
   Above the threshold, pass the category to the rules table like any
   other fact. Below it, send the case to a person with the model's
   guess shown as a suggestion.
   
   The model never picks the route itself. It answers "what is this
   about?", and the rules answer "what happens next?".

4. 4

   Send unmatched cases to a person

   A default route hides the cases the rules missed.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas. When no rule matches, post the case in the process
   owner's Slack channel with the facts, the category and why no rule
   applied. Let them pick the route in the message.
   
   Record each of these cases. If the same kind keeps arriving, that is
   a rule the table is missing.

5. 5

   Record which rule decided

   Every outcome should be explainable in one sentence.

   Copy

   Write the decision to the source record and to Snowflake: the rule
   that matched, the facts it matched on, the category and its
   confidence, and the route taken. Report each week on how often each
   rule fires, how many cases fell through to a person, and which rules
   never fire at all.

6. 6

   Validate it, then hand the table to the owner

   Because the rules change more often than the workflow should.

   Copy

   Run the per-step checks and the whole-workflow audit before this goes
   live. Test a case for every rule, a case that matches two rules, one
   with a missing value, one with free text the model is unsure about,
   and one that matches nothing.
   
   Then open the same workflow in Tray Build so the process owner can
   change the rules, the categories and the threshold in the visual
   canvas without a deployment.

What it connects to

Facts come from the systems that hold them, the rules live where the owner can edit them, and the decision goes back to the record.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides