Changing an automation after launch: a practical change request guide

Start with the behavior you already agreed

Find the current workflow brief, acceptance tests and operating instructions. Describe the observed problem with a synthetic example. If a report omits a field that the accepted specification requires, record it as a suspected defect. If the team now wants an additional data source or audience, record the proposed addition. The agreed service terms determine what work is included; a label alone cannot settle a billing question.

Our recommendation is to keep three separate decisions visible: whether the request is useful, whether the team accepts the effort and commercial impact, and whether the tested change is ready to run. One person may make all three decisions in a tiny business, but each decision still needs a clear object. A request to investigate is insufficient evidence of approval to release.

Use a small change record with an exact boundary

Give the request an identifier and an owner. Record the current workflow version, the desired difference, affected inputs and outputs, required access, excluded work, acceptance tests, expected running-cost impact and a recovery owner. Include the estimate or mark it as pending. Leave credentials and real customer records out of the request; reference controlled records where necessary.

NIST’s configuration-management guidance treats security as part of configuration management and describes managing and monitoring configurations to reduce organizational risk while supporting business functionality. It addresses federal information systems; the lightweight change record here is Croissant’s practical recommendation for smaller teams, rather than a claim of NIST certification. ^[1]

An exclusion should be concrete. “Add a draft comparison of this week and last week for one reporting template” is a reviewable boundary. “Make reporting smarter” leaves the owner guessing about data sources, client delivery and ongoing support. Keep the existing reporting guide as the starting point: [agency reporting automation](/blog/ai-weekly-reports/).

Worked example: adding a comparison to an agency report

This example is entirely synthetic. An agency already prepares a weekly draft from an approved spreadsheet export. Its account manager asks for a previous-week comparison. The current approved workflow drafts a single-week summary for internal review; it has no permission to email clients. The proposed change adds one comparison paragraph, while client sending remains outside scope.

Change CR-014 specifies that both exports must belong to the same client, use matching metric definitions and cover the agreed reporting intervals. For the example, last week has 40 enquiries and this week has 50. The expected statement is “Enquiries rose by 10, from 40 to 50, a 25% increase.” A named reviewer checks the calculation against the exports before accepting the draft.

The acceptance pack includes three additional cases. If last week is missing, the draft states that a comparison is unavailable. If last week is zero, it reports the absolute change without a percentage increase. If the files identify different clients, the workflow stops the comparison and flags the mismatch for review. These are proposed test outcomes, not measured production results.

The agency approves only that template and those inputs. Adding advertising-platform access, scheduling automatic delivery or rewriting earlier reports would need a separate impact assessment. This boundary gives the builder something testable and gives the buyer a way to decline extra work without losing the original request.

Approve the version that was actually tested

Ask the builder to show the before-and-after output and the acceptance results. Record which revision was reviewed, the reviewer and any conditions. A comment such as “interesting idea” should remain feedback. “Approved for release” should identify the revision, environment and scope. If the implementation changes materially after review, reassess the affected tests and obtain the appropriate decision again.

For teams using GitHub, pull request reviews distinguish general comments, approvals and requests for changes. Repository administrators can require approvals before merging. Those are GitHub capabilities; a business still needs to define who may approve commercial scope and who may release the workflow. A code review does not answer those business questions automatically. ^[2]

For a fuller set of sample cases, use the [workflow test pack](/blog/test-ai-workflow-before-launch/). Keep supporting evidence proportionate: a changed label needs less testing than new write access to a CRM.

Plan the first run and the way back

Name the person who will check the first changed run. Preserve the previous configuration and define the condition for pausing the workflow. In the synthetic reporting example, a client mismatch or unsupported comparison blocks acceptance. The reviewer can return to the single-week draft process while the comparison is investigated.

Restoring configuration does not reverse an email already sent or a record already overwritten. Before a change adds external actions, decide how the team will identify affected records, prevent repeated actions and correct mistakes. Use the existing [recovery runbook](/blog/automation-failure-recovery-runbook/) for incident handling. This article covers planned changes; urgent failures may require the team’s separate emergency process.

Know when a change request needs discovery first

If nobody can identify the authoritative data source, the expected output or the person entitled to approve it, start with a bounded investigation. Ask for a written finding and options before commissioning a production change. An estimate based on unknown access or undocumented business rules deserves explicit assumptions.

A change record cannot guarantee correctness, settle contractual disputes or make sensitive processing appropriate. Its value is making decisions inspectable. Review actual supplier terms and relevant specialist requirements when they affect the work. For a scoped conversation with Croissant, [use the contact form](/#contact) and describe the current workflow, the desired difference and the systems involved. Share a synthetic example rather than private customer data.

Implementation checklist

• Identify the current approved workflow and the exact behavior to change.
• Record affected systems, permissions, excluded work and commercial assumptions.
• Name the request owner, business approver and release owner.
• Define synthetic acceptance cases, including missing and mismatched inputs.
• Record test evidence and approval against the specific revision.
• Choose first-run checks, pause conditions and a recovery owner.
• Update operating instructions after the accepted change is live.