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.

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.

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.

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.

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.