The value you wired in once and never looked at again
One VAT rate, typed into six different workflows, took a whole afternoon to change. Hardcoded values hide in almost every automation setup. Here is how to spot the ones that will quietly cost you money and pull them out first.
One tax rate, typed into six different places
When a client's VAT handling changed, we needed to update a single number. It took most of an afternoon. Not because the change was hard, but because the old rate was sitting inside six separate workflows, each in a slightly different spot, and nobody had a list of where. We opened every scenario, read through every module, and still weren't fully sure we had caught the last one. That uncertainty, did we get them all, is the real cost of a hardcoded value.
A hardcoded value is any piece of information typed straight into a single step instead of living somewhere central. The recipient address in a mail module. The folder ID a document gets filed into. A price threshold buried inside a condition. When you build it, it looks like the most reasonable thing in the world. You need an address, you type the address, the test goes green.
Why it feels correct right up until it isn't
The trap is that a hardcoded value is never wrong on the day you set it. It becomes wrong later, when the world around it shifts and no one remembers the value is there. The address was fine until the person left. The folder ID was fine until someone reorganised the drive. The tax rate was fine until the law changed. Nothing in the workflow announces the problem. It keeps running, confidently, on a value that stopped being true weeks ago.
I see four kinds again and again. People, first: a fixed email, a name, a phone number. People change teams, go on leave, quit, and the workflow keeps writing to a mailbox no one reads. Then identifiers: the ID of a folder, a table, a record, a pipeline stage, stable right until someone tidies up the target system and the old ID points at nothing. Then rules expressed as bare numbers: a tax rate, a threshold, a deadline, sitting in five places at once and documented in none. And finally endpoints: a test URL that made it into production, a connection pointing at a system that was switched off long ago.
The part that makes cleanup painful
The individual value is rarely the hard part. The hard part is that you don't know how many there are or where they live. When something has to change, you can't fix it in one place. You open every workflow, hunt through every step, and hope you didn't miss one. A missed value doesn't crash. It quietly produces wrong numbers, and wrong numbers only get noticed once they have become expensive.
How we build it instead
The rule we hand every setup is short. Any value that can change, or that gets used in more than one place, does not belong inside the workflow. It belongs somewhere the workflow looks it up. In practice that is often a small configuration table, a database, or a datastore inside the automation tool itself. The recipient for payment failures is this role. The current tax rate is this. The threshold for large orders is that. The workflow asks for the value at runtime instead of carrying it around. When something changes, you change it once, and every workflow follows.
The second principle is about people. Send notifications to roles, not to individuals. Not to one person's inbox, but to a maintained function mailbox or a distribution list that gets updated when someone leaves. A role survives a staffing change. A private address does not.
A check you can run today
You don't need a project to start. Take your three most important automations and, for every fixed value in them, ask one question: what happens if this value changes and no one thinks to update it here? For most values the answer is harmless. For a few, your stomach drops, and those are the ones to pull out first.
The departed employee was never supposed to be a problem. Had the alert gone to a role instead of a person, his leaving would have changed nothing. Instead, two years of unhandled payment failures sat in a mailbox, invisible, because the value that routed them there was buried in a workflow no one had opened since the day it was built.
If you want to know which wired-in values are sitting in your automations, and which of them would cost you real money on a bad day, we're happy to look with you. Our free automation check walks through your most important workflows and shows you where a forgotten value can turn into a trap.