A workflow needs a shape before it needs nodes
Start with the operational story: what triggers the workflow, what data is required, which systems are touched, what can fail, who gets alerted, and how a failed run is retried.
When this is not written down, the workflow becomes a visual maze. It may work during a demo, but the next person cannot safely operate it.
Trigger -> Validate payload -> Normalize data -> Call API
-> Store result -> Notify owner -> Error workflowCredentials are part of the architecture
Do not treat credentials as a final setup detail. The account, permissions, scopes, and rotation plan affect what the workflow can safely do.
Try the idea
Workflow runbook
Trace a client-ready automation path.
Every run starts with a known source and sample payload.
Handoff notes make automations real
A workflow is not production-ready until someone else can understand normal runs, failed runs, expected alerts, and safe retry steps.
Production notes for n8n automations
Automation quality is measured after the happy path fails. A workflow should explain what triggered it, what data it needs, what systems it touches, and how someone can recover a failed execution.
Treat credentials, retries, error workflows, idempotency, and handoff documentation as part of the build, not cleanup after the demo.
Conclusion
The difference between a demo automation and a production automation is whether another person can operate it when it fails.