One flow, four clients, no copy and paste

<h2>The agency problem</h2><p>A consultancy sets up the same intake automation for every client. Same trigger, same field map, same alert. What differs is four values: which board, which channel, which owner, which CRM portal. By the fourth client they have four flows. By the twelfth, they have twelve, and a change to the shared logic is an afternoon of careful, error prone repetition.</p><p>This is the most common piece of feedback we received in our first year, and it arrived from in house teams too. Anyone running the same process across regions, brands or business units has the same problem with different vocabulary.</p><h2>What a template holds</h2><p>A template is a flow with its logic intact and its connections removed. It keeps the trigger type, the filters, the field map, the error handling and the step order. It deliberately does not keep account tokens, specific board or database identifiers, channel names, or anything that would let one client's flow reach into another client's data.</p><p>That split is the whole design. Everything above the line is what you spent your expertise on. Everything below it is configuration that changes per deployment and should never be copied by hand.</p><h3>Variables instead of hardcoded identifiers</h3><p>A template refers to destinations by name and resolves them per workspace:</p><pre><code>trigger: form_submission (source: {{ workspace.form_id }}) create: card on {{ workspace.trello_board }} / list Intake notify: {{ workspace.alert_channel }} assign: {{ workspace.default_owner }} </code></pre><p>Applying the template to a workspace asks four questions and nothing else. Twenty minutes of building becomes about ninety seconds of answering, and more importantly the answers are recorded in one place where you can audit them.</p><h2>Rolling out a change to twelve copies</h2><p>Templates would be a modest convenience if they were only a starting point. The part that earns its keep is what happens when the shared logic changes: a new required field on the destination, a filter to exclude test submissions, a corrected date mapping.</p><p>Edit the template and you get a list of every workspace running it, with three choices per row.</p><ul><li><strong>Apply now.</strong> The workspace picks up the change on its next run.</li><li><strong>Apply at a time you pick.</strong> Useful when a client has agreed a change window and you do not want a surprise on a Monday morning.</li><li><strong>Detach.</strong> The workspace keeps its current version and stops following the template. Sometimes a client genuinely needs a different rule, and forcing them back into the shared shape is worse than admitting the divergence.</li></ul><p>Detach exists because we tried building this without it. Without an explicit exit, people work around inheritance by copying the flow anyway, and now you have an untracked fork that looks like a template but is not.</p><blockquote><p>The change window option is why we adopted it. We support nine clients on the same intake flow and three of them have opinions about when anything moves.</p><p>Haruki Oyelowo, founding partner at Meridian Ops Partners</p></blockquote><h2>The conflict question</h2><p>Somebody will edit a live flow that follows a template. We had three options and picked the third.</p><ol><li>Refuse the edit. Clean, and it makes an urgent client fix impossible at the exact moment you need one.</li><li>Allow the edit and silently overwrite it on the next template apply. The worst option, and the most common in tools we looked at.</li><li>Allow the edit and mark the flow as modified. The next template update shows the conflict, names the steps that differ, and asks which version wins.</li></ol><p>The third costs a decision, once, at a moment when somebody is already paying attention. The second costs a Tuesday.</p><h2>Where we drew the line</h2><p>Templates are not a scripting language and we are keeping it that way. There are no loops, no conditionals beyond the filters the builder already supports, and no way for one workspace to read another workspace's data. The moment a template can branch on arbitrary logic it becomes code without a code review, and the person maintaining it a year later will not be the person who wrote it.</p><p>What we did add is a version history. Every template revision is kept with a note and the person who made it, and any workspace can roll back to a previous revision on its own without affecting the others. That is enough structure to run twelve deployments and little enough to explain in a paragraph.</p><h2>If you are starting today</h2><p>Build the flow properly for one client first. Get it wrong, fix it, run it for two weeks, and only then convert it into a template. A template made on day one records your assumptions before you learned which of them were wrong, and every workspace inherits them.</p>