Client Approval Belongs to a Workflow Version

The platforms are getting clearer about what is live

n8n 2.0 separated saving from publishing. A saved workflow can diverge from the published version while the older production version keeps running. Zapier follows the same basic pattern: edits live in a draft until publication creates a new version. Make keeps manually saved scenario versions and can restore them. HubSpot records workflow revisions, including what changed, when, and who made the change.

That is useful progress. It gives the builder a better technical record of the artifact.

It does not answer the client question: which version did we approve?

Version history shows that the workflow changed. Approval records whether the client accepted the scope, consequences, timing, and risk of that change. They are related records, but they are not interchangeable.

Approval needs an object

“Approved” is too loose to operate from. A usable approval should point to:

• The request the client made.
• The scope the agency proposed.
• The person who approved it, and in what role.
• The workflow version or structural baseline in front of them.
• The date and source of the decision.

This does not require a formal change board or a signature process for every small edit. It requires enough specificity that another operator can tell what the yes covered.

Suppose the request is to route enterprise leads to a named salesperson. The approved scope changes one condition and one destination. If the implementation also adds a fallback branch, changes the workflow schedule, and writes to a second system, the original approval should not be stretched to cover all three.

The operating rule is simple: approval follows scope. If the implemented structure moves beyond the scope, stop and resolve the difference before publication.

Structural changes should reopen the decision

Not every edit is material. Renaming a step or moving it on the canvas may not change what the automation does. The edits that deserve attention are the ones that can change behavior or responsibility:

• A step, module, or action is added or removed.
• Routing or execution order changes.
• A new system receives or supplies data.
• A schedule or activation state changes.
• An error path, fallback, or human review step changes.

A structural comparison can surface many of these changes. It cannot see everything that matters. A changed field mapping, filter expression, prompt, credential, or value may alter the outcome without changing the visible shape of the workflow.

That is why a diff is a decision aid, not a verdict. The operator still has to ask whether the implemented version stays inside the approved scope.

If it does, record that judgment. If it does not, bring the delta back to the client. The client does not need to reapprove the whole relationship or read a technical export. They need a short description of what changed beyond the earlier scope and what that changes for them.

Re-verification should follow the affected path

A changed version does not always justify rerunning every test. It does justify retiring proof that no longer covers the live structure.

Start with the difference between the approved version and the version ready to publish. Then build the verification plan around the affected path.

For a new routing branch, that usually means checking:

• The original path still works.
• The new branch receives the right records.
• The fallback handles unmatched records.
• The destination system receives the expected result.
• An error does not leave the record in an unknown state.

The exact checks depend on what the workflow is allowed to do. A read-only enrichment step and a workflow that changes CRM ownership do not carry the same risk.

Native tools help with the technical work. n8n can keep a stable published version running while a draft changes. Zapier records the version used for a run. Make can use trigger data from a previous run to test the current scenario version. HubSpot can simulate a record's path through the current workflow without executing the actions.

Those tools make testing and rollback more practical. They still do not decide whether the client approved the behavior being tested.

Close the record against what actually went live

The final record should name the version that was published, not only the version that was proposed.

It should hold the request, the approved scope, the implemented difference, the verification plan, the observed result, and any remaining exception. If the final version differs from the approved baseline, the record should show who decided the change stayed within scope or where the revised approval was captured.

This matters most when someone else has to answer later. The client asks why a record went down a new branch. A teammate inherits the workflow. A failed run points back to a version that has already been replaced. The answer should not depend on reconstructing intent from version history and messages.

Platform history is necessary technical evidence. It is not the client decision.