Sanity check: case-based automation workflow with file intake, anonymization, and timed lifecycle management

[vmdials]

I’m designing a case-driven automation workflow and want to confirm whether n8n is a good fit architecturally before building.
This is not a simple linear automation — it behaves more like a lightweight case management pipeline with file handling and lifecycle rules.
High-level workflow:

1. A user submits an intake survey.
2. A case record is created with:
   o internal case ID
   o public case code
   o structured survey data
   o PII stored separately from assessment data
3. The system assigns and updates case statuses throughout the workflow.
   Eligibility + intake phase:
4. User gains portal access tied to case code.
5. User uploads multiple assessment PDFs over time.
6. Each upload must be matched to the correct case.
7. Files are stored in a case-specific container/folder.
8. Case status updates automatically as files arrive.
   Processing phase:
9. Assessment PDFs are parsed into structured data.
10. An anonymized case dataset is generated (PII stripped).
11. A report is generated from anonymized data.
12. PII is reinserted only in the final output.
13. A branded PDF report is created and stored.
    Delivery phase:
14. User receives time-limited portal access to download report.
15. Access window is enforced automatically.
    Lifecycle management:
16. Timers track:
    • portal expiration
    • retention deadlines
    • archive/delete rules
17. After expiration:
    • files are archived or deleted
    • portal is locked
    • case moves to closed state
    Admin layer:
18. Admin can view case status and retrieve files.
19. System logs failures and sends notifications.
20. Case behaves like a state machine with structured transitions.
    Key requirements:
    • asynchronous file ingestion
    • case-based state tracking
    • timed triggers / delayed execution
    • safe handling of PII vs anonymized datasets
    • reliable long-running workflows
    • auditability + failure recovery
    Questions:
    • Is n8n stable for case-driven, multi-step workflows with delayed triggers?
    • Best pattern: one workflow per case vs central dispatcher?
    • How should case state be persisted (DB, external store, n8n data)?
    • Known limits around long-running timers?
    • File handling best practices at this scale?
    • Recovery strategy if a workflow crashes mid-case?
    • Is this a good use case for n8n or pushing it toward a custom backend?
    I’m optimizing for reliability, auditability, and long-term maintainability over speed of build.
    Would appreciate architectural guidance before implementation.

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[barn4k]

hello @vmdials

@vmdials

Is n8n stable for case-driven, multi-step workflows with delayed triggers?

Yes, but better to use webhooks/message queue instead of relying on delayed triggers

@vmdials

Best pattern: one workflow per case vs central dispatcher?

Dispatcher flow with multiple sub-workflows is better

@vmdials

How should case state be persisted (DB, external store, n8n data)?

You may use anything you want. the simples one is to use built-in data tables.

@vmdials

Known limits around long-running timers?

n8n may keep executions for whatever time you need, however, it’s not a good approach in general. Use webhooks instead.

@vmdials

File handling best practices at this scale?

Store files outside of n8n. Only use it for downloading/uploading/processing purpose

@vmdials

Recovery strategy if a workflow crashes mid-case?

It’s up to you how you will set the recovery logic. The simplest way is to place new/waiting-for-processing cases in a queue (e.g., RabbitMQ/Redis/SQS and so on) and remove an item from the queue only when the workflow completes successfully.

@vmdials

Is this a good use case for n8n or pushing it toward a custom backend?

• all processing stuff - yes
• all user-interactions stuff - no, you will need a portal. n8n is just an automation platform; it’s not a portal for clients