A workflow you built to try something out is different from one your business depends on.<\/p>\n
When it was an experiment<\/strong>, a failure meant you noticed and re-ran it.<\/p>\n Now<\/strong>, a failure means orders do not reach your ERP, or reference data goes stale, or a customer does not get a reply.<\/p>\n Nothing about the workflow changes. Everything about what surrounds it does.<\/strong><\/p>\n The single most important thing on this page.<\/strong><\/p>\n A workflow that fails silently is worse than no workflow, because everyone assumes it is running. The gap is discovered weeks later, and by then nobody can reconstruct what was missed.<\/p>\n Four things:<\/strong><\/p>\n An error workflow.<\/strong> N8N can run a second workflow when the first fails. Have it notify a person, with the workflow name and the error.<\/p>\n Alerts to a named person.<\/strong> Not a shared inbox. Not a log file. Somebody who will act.<\/p>\n Alerts on silence too.<\/strong> A scheduled job that did not run produces no error. Monitor for the absence<\/strong>, not just the failure.<\/p>\n Enough context in the alert<\/strong> to act on. Which workflow, which record, what failed.<\/p>\n FIGURE 1: MAKING FAILURE VISIBLE<\/p>\n An error workflow<\/p>\n A named recipient<\/p>\n Monitoring for silence<\/p>\n Context in the alert<\/p>\n Do not build on the instance your business runs on.<\/strong><\/p>\n A workflow being developed will fail, loop, and send test messages. On a production instance that means real customers receiving test notifications, or test records appearing in your ERP.<\/strong><\/p>\n Two instances, at minimum:<\/strong><\/p>\n Production.<\/strong> Live workflows only. Changes arrive tested.<\/p>\n Development or test.<\/strong> Where things get built and broken.<\/p>\n And point test workflows at test systems.<\/strong> A development workflow connected to your live Odoo is a production workflow that nobody has admitted to.<\/p>\n An automation platform holds keys to everything it connects to. That makes it valuable to protect.<\/p>\n Four practices:<\/strong><\/p>\n A dedicated account per integration.<\/strong> Never a person’s login. When they leave, nothing breaks.<\/p>\n Minimum permissions.<\/strong> A workflow that reads orders should not be able to delete them.<\/p>\n API keys rather than passwords<\/strong> where supported. Revocable individually, and they survive two-factor authentication.<\/p>\n Documented.<\/strong> Which workflow uses which account, and who owns it. Without this, nobody can safely rotate anything.<\/strong><\/p>\n Twenty workflows built inconsistently is far more than four times the work of five.<\/p>\n A convention that works:<\/strong><\/p>\n Descriptive workflow names.<\/strong> “Shopify order to Odoo”, not “Workflow 7”.<\/p>\n Descriptive node names.<\/strong> “Search Odoo for existing partner”, not “HTTP Request3”.<\/p>\n Sticky notes explaining why.<\/strong> The what is visible on the canvas. The why is not.<\/p>\n One workflow, one job.<\/strong> A workflow doing six unrelated things cannot be changed safely.<\/p>\n Shared sub-workflows<\/strong> for anything repeated \u2014 a login sequence, a lookup, a notification format. So when it changes, you fix it once.<\/strong><\/p>\n Every workflow needs a named owner.<\/strong><\/p>\n Not a team. A person, who:<\/p>\n When that person leaves, ownership transfers explicitly.<\/strong> The most common cause of an abandoned workflow is that its author moved on and nobody inherited it.<\/p>\n FIGURE 2: WORKFLOWS THAT LAST AND ONES THAT DO NOT<\/p>\n Lasting<\/p>\n Becoming a liability<\/p>\n If you self-host, the database holding your workflows and credentials is critical.<\/strong><\/p>\n Back it up daily<\/strong> if workflows change regularly.<\/p>\n Store a copy off the server.<\/strong> A backup on the same machine does not survive the machine.<\/p>\n Test a restore quarterly.<\/strong> Restore into a separate instance, open it, check the workflows are there and the credentials work.<\/p>\n An untested backup is not a backup.<\/strong> This is true of your automation platform as much as your ERP.<\/p>\n The proactive part, and it separates well-run automation from constant firefighting.<\/p>\n Keep a list:<\/strong> which workflows depend on which systems.<\/p>\n Then:<\/strong><\/p>\n Subscribe to release notes<\/strong> for the services you depend on. API changes are usually announced.<\/p>\n Test after any known update<\/strong>, rather than waiting for the failure.<\/p>\n Include workflows in your Odoo upgrade testing.<\/strong> Odoo’s data model changes between versions, and integrations fail quietly afterwards.<\/p>\n The dependency list is what makes this possible.<\/strong> Without it, an announced API change means checking everything or nothing.<\/p>\n The most valuable habit on this page<\/strong>, and the least common.<\/p>\n A scheduled job that compares two systems and reports disagreements.<\/strong><\/p>\n Order counts in Shopify against Odoo. Records imported against rows in the source file. Items in Jira against items in Monday.<\/p>\n Why it matters:<\/strong> sync failures are silent. Nothing errors \u2014 the two systems just drift apart.<\/p>\n A weekly reconciliation catches that.<\/strong> Without one, you find out at month-end, or when a customer asks about an order you never received.<\/p>\n FIGURE 3: WHAT PRODUCTION ADDS<\/p>\n Separate environments<\/p>\n Alerts to a person<\/p>\n An owner and documentation<\/p>\n Reconciliation<\/p>\n Once a year, per workflow:<\/p>\n Is it still running?<\/strong> Some quietly stopped and nobody noticed.<\/p>\n Is it still needed?<\/strong> The process may have changed.<\/p>\n What has it cost to maintain?<\/strong><\/p>\n Is the benefit still there?<\/strong><\/p>\n Switching one off is a valid outcome.<\/strong> A workflow that costs more to maintain than it saves should go. That is a good decision, not an admission of failure.<\/p>\n Production is not a bigger version of experimenting. It is visible failure, separate environments, named owners, and reconciliation.<\/strong><\/p>\n Alert on silence as well as errors<\/strong> \u2014 a scheduled job that did not run produces no error message.<\/p>\n Keep a dependency list<\/strong> so an announced API change means checking three workflows, not all of them.<\/p>\n And add reconciliation.<\/strong> Sync failures do not announce themselves, and drift is the failure that costs most because you find it late.<\/p>\n Running automations your business depends on?<\/p>\n Get in touch. We set up alerting, environments and reconciliation \u2014 the parts that decide whether automation is an asset or a liability.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" The shift A workflow you built to try something out is different from one your business depends on. When it was an experiment, a failure meant you noticed and re-ran it. Now, a failure means orders do not reach your ERP, or reference data goes stale, or a customer does not get a reply. Nothing […]<\/p>\n","protected":false},"author":3,"featured_media":9298,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28],"tags":[],"class_list":["post-9297","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-n8n"],"yoast_head":"\nFailure must be visible<\/h2>\n
\n
\n
\n
\n
Separate your environments<\/h2>\n
Credentials<\/h2>\n
Naming and structure<\/h2>\n
Ownership<\/h2>\n
\n
\n
\n
Backups<\/h2>\n
Watching for changes upstream<\/h2>\n
Reconciliation<\/h2>\n
\n
\n
\n
\n
Reviewing what you have<\/h2>\n
The short version<\/h2>\n