# If your n8n workflow can move money or lock accounts, it's not just a workflow anymore. It's software **URL:** \ **Category:** Tips & Tricks\ **Created:** [14. November 2026 um 12:37 UTC](https://community.n8n.io/t/if-your-n8n-workflow-can-move-money-or-lock-accounts-its-not-just-a-workflow-anymore-its-software/328699 "2026-11-14T12:37:33Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Kemal\_Automation](https://dub1.discourse-cdn.com/n8n/user_avatar/community.n8n.io/kemal_automation/32/175107_2.png) [@Kemal\_Automation](https://community.n8n.io/u/Kemal_Automation)\ **Post date:** [14. November 2026 um 12:37 UTC](https://community.n8n.io/t/if-your-n8n-workflow-can-move-money-or-lock-accounts-its-not-just-a-workflow-anymore-its-software/328699/1 "2026-11-14T12:37:33Z")
The scariest n8n failure isn’t the one that crashes. It’s the one that succeeds twice. A webhook fires the same event again. Your AI node returns `"decision": "approve"` both times. Both executions pass every check you built. Both run the action. Nothing errored. Nothing alerted. The logs look perfect. That’s the gap I keep running into: n8n makes it easy to build workflows that work in testing. Production asks different questions: - What if the model returns malformed JSON? - What if the API times out after it executed the action? - What if two executions update the same record? - What if the model is confidently wrong? My position is that n8n should orchestrate, not decide. AI evaluation → Python validation → deterministic decision → n8n orchestration → audit log Anything that approves, blocks, or escalates gets idempotency keys, schema validation, and a decision log in code, where I can test it. n8n handles the routing, retries, and glue around it. I know this will annoy some people. If you run business-critical decisions entirely inside n8n and it holds up, I want to hear how, especially how you handle idempotency and partial failures. Where’s your line between a workflow and a system that needs real engineering? ---
**Author:** ![rambozambo](https://avatars.discourse-cdn.com/v4/letter/r/eb9ed0/32.png) [@rambozambo](https://community.n8n.io/u/rambozambo)\ **Post date:** [14. November 2026 um 15:33 UTC](https://community.n8n.io/t/if-your-n8n-workflow-can-move-money-or-lock-accounts-its-not-just-a-workflow-anymore-its-software/328699/2 "2026-11-14T15:33:55Z")
The failure you open with is the one I keep coming back to: the workflow that succeeds twice. Every check passes, both executions are legitimate as far as the log is concerned, and the duplicate only exists as a business fact, not as an error anywhere. Your pipeline shape is right, and I would push hardest on the last box. An audit log in your own code answers questions while you still have access and the client still has you. The questions that actually hurt arrive later: a chargeback, a locked account, a client asking six weeks on why a payment was approved, sometimes after the engagement has ended. At that point the decision record has to stand on its own, readable by someone who was never in the run. What has worked for me is freezing one record per decision at decision time, outside the workflow: the exact inputs, the raw model output, the validator’s verdict, and the action taken, hashed together so any later copy can be checked byte for byte against the original. Two things fall out of that. First, your double-approve case stops being silent: the second decision produces a second record against the same business key, and the pair is visible to anyone reviewing, instead of two green executions. Second, a malformed-JSON decision and a confidently-wrong decision look different in the record, because the validator’s verdict is stored next to the output it judged, not summarized away. n8n orchestrating and code deciding is a split I agree with. I would just add: the record of the decision should outlive both.