Already tested voucher + invoice flows — looking for 1 different n8n case

Help me Build my Workflow
, ,
1

I’ve already tested 2 anonymized workflow cases locally:

  • voucher validation
  • invoice extraction / strict schema validation

Both were useful, but now I’m looking for a third case that is meaningfully different.

Not another voucher-like or invoice-like example.

What I’d like next is something more like:

  • classification / routing
  • compliance / policy checks
  • a workflow where bad structured output creates the wrong downstream action, not just bad extracted data

What I’m testing is still very simple:
should the workflow continue downstream, or should it stop safely here?

A short outline is enough first.
I don’t need the full payload immediately.

What helps:

  • rough payload shape
  • target schema
  • short note on downstream risk
  • polling or webhook preference

What I can return:

  • whether the run ended in succeeded or failed_safe
  • a short reason if relevant
  • a receipt reference

This is not broad onboarding and not a product pitch.
I’m just trying to see whether this holds up across different workflow types.

Public kit:

If you have a case from a different workflow/team, reply here or DM me.

2

classification/routing is a clean fit for what you’re describing — incoming support email arrives, AI classifies it as support/sales/spam, downstream routes accordingly (create ticket, push to CRM, discard). the structured output risk is subtle: model returns ‘Sale’ instead of ‘sales’, the routing condition silently takes the wrong branch — no error thrown, wrong team gets the item. minimal schema: {class: enum['support', 'sales', 'spam'], confidence: float}, webhook trigger. downstream risk is higher than data extraction because the failure is invisible.

3

This is very helpful — thank you.

Yes, this is much closer to the kind of third case I was looking for.

The support / sales / spam routing boundary is a good fit because the downstream risk is not “bad extracted data,” but the workflow taking the wrong action without throwing a hard error.

For the current narrow Phase 1 test, the cleanest first version is:

  • webhook-triggered input
  • target schema like { class: enum[‘support’,‘sales’,‘spam’], confidence: float }
  • route only if the result passes the boundary, otherwise stop safely

If you’re open to it, the smallest next step would be:

  • a rough sample payload shape
  • the target schema you would actually use
  • one short note on what the downstream action would be for each class

A short outline is enough first — no need for a full payload yet.
If easier, feel free to DM.

4

Great to hear that helps! For the payload, you’d have something like:

{
  "email": "[email protected]",
  "subject": "...",
  "body": "..."
}

And the target schema you mentioned:

{
  "class": "support|sales|spam",
  "confidence": 0.95
}

For downstream: Create Zendesk ticket if ‘support’, push to Pipedrive if ‘sales’, skip if ‘spam’. You can set a confidence threshold (e.g., >0.8) to route, anything below goes to a review queue for safety.

Let me know if you want to refine the schema further!

5

This is excellent — thank you.

This gives me enough to treat it as the next candidate case on my side.

The webhook shape, schema, and downstream actions are all clear, and this is a good fit because the main risk is wrong downstream branching/action rather than just bad extracted data.

On my side I’m separating it into two narrow layers:

  • schema / enum / malformed-structure boundary
  • threshold-policy boundary

So the first checks are things like:

  • valid structured output passes
  • invalid enum or malformed output stops safely

Then I can treat the confidence rule as the next policy layer:

  • route if confidence > 0.8
  • otherwise send to review

One thing I’ll keep explicit on my side:
schema-valid but semantically wrong classification is still a separate limitation unless there’s an expected-label or stronger routing-policy contract.

One quick clarification:
should I treat the 0.8 threshold as an example policy, or as the intended routing rule for this case?

This is already very helpful — thank you.

6

treat it as an example policy — a reasonable starting point, not a fixed contract. the right threshold depends on your data and how much risk you’re willing to carry from borderline classifications. for strict downstream routing (auto-creating tickets or pushing to a CRM), you’d probably push higher (0.85–0.9). keeping it as a configurable parameter rather than a hardcoded rule is the right call, so you can tune it per case as you test the two layers separately.

7

That makes sense — thank you.

I’ll treat the threshold as a configurable policy parameter, not a fixed contract.

So on my side I’ll keep the case split into:

  • schema / enum / malformed-structure boundary
  • threshold-policy boundary

And I’ll keep semantic-but-schema-valid wrong classification as a separate current limitation unless a stronger expected-label or routing-policy contract exists.

This is already enough for me to move the case forward on my side.
Thanks again.

8

good luck with the test run — the two-layer split makes sense as a way to isolate where failures actually come from. curious to see how the semantic-but-schema-valid edge cases behave in practice.

9

Thanks again — this was genuinely very helpful.

I was able to use your example as the third materially different case in my narrow Phase 1 evaluation.

I kept the scope intentionally narrow on my side:

  • schema-boundary observation
  • provisional threshold-policy observation

I’m not treating it as proof of semantic correctness or a fixed threshold contract, but it was more than enough to move the case forward in a meaningful way.

I really appreciate you taking the time to spell out the payload shape, schema, downstream actions, and threshold guidance.

10

glad it held up as a usable third case — the two-layer boundary split is a clean way to structure it. good luck with the runs.

1 Like