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 about the workflow changes. Everything about what surrounds it does.

Failure must be visible

The single most important thing on this page.

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.

Four things:

An error workflow. N8N can run a second workflow when the first fails. Have it notify a person, with the workflow name and the error.

Alerts to a named person. Not a shared inbox. Not a log file. Somebody who will act.

Alerts on silence too. A scheduled job that did not run produces no error. Monitor for the absence, not just the failure.

Enough context in the alert to act on. Which workflow, which record, what failed.

Separate your environments

Do not build on the instance your business runs on.

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.

Two instances, at minimum:

Production. Live workflows only. Changes arrive tested.

Development or test. Where things get built and broken.

And point test workflows at test systems. A development workflow connected to your live Odoo is a production workflow that nobody has admitted to.

Credentials

An automation platform holds keys to everything it connects to. That makes it valuable to protect.

Four practices:

A dedicated account per integration. Never a person’s login. When they leave, nothing breaks.

Minimum permissions. A workflow that reads orders should not be able to delete them.

API keys rather than passwords where supported. Revocable individually, and they survive two-factor authentication.

Documented. Which workflow uses which account, and who owns it. Without this, nobody can safely rotate anything.

Naming and structure

Twenty workflows built inconsistently is far more than four times the work of five.

A convention that works:

Descriptive workflow names. “Shopify order to Odoo”, not “Workflow 7”.

Descriptive node names. “Search Odoo for existing partner”, not “HTTP Request3”.

Sticky notes explaining why. The what is visible on the canvas. The why is not.

One workflow, one job. A workflow doing six unrelated things cannot be changed safely.

Shared sub-workflows for anything repeated — a login sequence, a lookup, a notification format. So when it changes, you fix it once.

Ownership

Every workflow needs a named owner.

Not a team. A person, who:

• Knows what it does and why
• Receives the failure alerts
• Fixes it or escalates it
• Knows which system changes might affect it

When that person leaves, ownership transfers explicitly. The most common cause of an abandoned workflow is that its author moved on and nobody inherited it.

Backups

If you self-host, the database holding your workflows and credentials is critical.

Back it up daily if workflows change regularly.

Store a copy off the server. A backup on the same machine does not survive the machine.

Test a restore quarterly. Restore into a separate instance, open it, check the workflows are there and the credentials work.

An untested backup is not a backup. This is true of your automation platform as much as your ERP.

Watching for changes upstream

The proactive part, and it separates well-run automation from constant firefighting.

Keep a list: which workflows depend on which systems.

Then:

Subscribe to release notes for the services you depend on. API changes are usually announced.

Test after any known update, rather than waiting for the failure.

Include workflows in your Odoo upgrade testing. Odoo’s data model changes between versions, and integrations fail quietly afterwards.

The dependency list is what makes this possible. Without it, an announced API change means checking everything or nothing.

Reconciliation

The most valuable habit on this page, and the least common.

A scheduled job that compares two systems and reports disagreements.

Order counts in Shopify against Odoo. Records imported against rows in the source file. Items in Jira against items in Monday.

Why it matters: sync failures are silent. Nothing errors — the two systems just drift apart.

A weekly reconciliation catches that. Without one, you find out at month-end, or when a customer asks about an order you never received.

Reviewing what you have

Once a year, per workflow:

Is it still running? Some quietly stopped and nobody noticed.

Is it still needed? The process may have changed.

What has it cost to maintain?

Is the benefit still there?

Switching one off is a valid outcome. A workflow that costs more to maintain than it saves should go. That is a good decision, not an admission of failure.

The short version

Production is not a bigger version of experimenting. It is visible failure, separate environments, named owners, and reconciliation.

Alert on silence as well as errors — a scheduled job that did not run produces no error message.

Keep a dependency list so an announced API change means checking three workflows, not all of them.

And add reconciliation. Sync failures do not announce themselves, and drift is the failure that costs most because you find it late.