Looking for 1 more real workflow case from another n8n team

Help me Build my Workflow
, ,
1

I’ve now tested 2 anonymized workflow cases locally:

  • voucher validation
  • invoice extraction / strict schema validation

Both were useful.

Now I’m looking for 1 more real case, ideally from a different workflow or team, to see whether this kind of boundary is useful beyond those first examples.

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

Good examples would be things like:

  • classification / routing
  • compliance / policy checks
  • document extraction
  • anything where bad structured output creates real downstream cost

What I need:

  • 1 sample payload
  • 1 target schema
  • 1 short note on what breaks downstream if it passes incorrectly
  • 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 just want one more real case from another workflow/team.

Public kit:

If sharing the full payload is hard, a short outline first is fine.
Reply here or DM me.

2

Um caso útil é a extração de faturas antes do roteamento ERP/AP.

Exemplo de payload de entrada:

{
  "file_url": "https://example.com/invoice_4821.pdf",
  "vendor_hint": "ABC Supplies",
  "received_at": "2026-06-01T10:15:00Z"
}

Esquema de destino:

{
  "vendor_name": "string",
  "tax_id": "string|null",
  "document_date": "YYYY-MM-DD",
  "currency": "ISO_4217",
  "line_items": [
    {
      "item_description": "string",
      "quantity": "number",
      "unit_price": "number",
      "total_price": "number"
    }
  ],
  "subtotal": "number",
  "tax_amount": "number",
  "total_amount": "number"
}

Risco a jusante se estiver errado:

  • fornecedor incorreto roteia a fatura para o fluxo de trabalho de AP errado

  • moeda incorreta ou total cria dados ruins de aprovação/pagamento

  • itens de linha ausentes quebra a reconciliação

  • subtotal + imposto não correspondendo ao total significa que o fluxo de trabalho deve parar, não continuar

Para esse tipo de caso, eu gostaria que o limite retornasse:

completed

ou:

failed_safe

com um motivo como:

schema_invalid
totals_mismatch
missing_required_field
low_confidence_vendor

Polling é adequado para esse tipo de fluxo de trabalho porque a extração de faturas geralmente não é crítica em latência. A parte importante é que a etapa ERP/AP a jusante seja executada apenas após as verificações de esquema e matemática passarem.

1 curtida