Editing an Automation

You edit an automation in the Advanced Builder — the same surface you use to create one. It is the single place to change everything about an existing automation: its identity, instructions, model, trigger, knowledge, tool access, guardrails, and active state. Open it with the Edit button on the automation detail page, which takes you straight to the builder for that automation.

The builder opens with your automation's current settings already loaded. Its sections run down one continuous page, and you can jump between them from the left-hand rail. See Create with the Advanced Builder for a full tour of the sections; this page focuses on what editing an existing automation looks like.

Two other surfaces edit the same automation and reach the same settings. Edit with the assistant on the detail page opens the chat builder against the automation you are looking at, and you finish in the builder's own Save. Your own connected AI assistant can edit a live automation directly, under your permissions. Both are described in Building and Maintaining Automations from Your AI Assistant.

What you can change

Turning an automation off and on

The Active switch lives in the Guardrails & Deploy section and appears once the automation has been saved at least once. Turn it off to pause the automation — it cannot run while inactive — and turn it back on, then save, to re-enable it. New automations start active, so the switch only matters when you are re-enabling one you previously paused.

Returning a live automation to dry run

Once an automation is promoted to production its write-capable tools are enabled. If you want to take it back to safe testing, use Return to dry run on the action bar. It asks you to confirm, then simulates connector writes until you promote again. An ordinary Save never changes this — dry run and production are only switched by the explicit Promote and Return to dry run actions. Both actions rewrite the shared MCP client's dry-run flag, so wait for active runs to finish or interrupt them before switching modes.

Testing a change before it goes live

Test agent always runs the configuration already saved on the server. It does not run unsaved fields from the browser draft. Save the change first if you want the test to exercise it.

To try a configuration change without changing the automation your team already depends on, create a staging copy from the automation detail page, edit and test that copy, then deploy it over production when you're happy with it. A staging copy's schedule never fires, and it gets its own webhook secrets and MCP client. It starts in dry run with exposure to your AI assistant, failure notifications and the support-ticket toggles switched off rather than inherited, with no Run as binding — a copy falls back to the owner's credentials until you bind it, so re-bind it if production runs as a specific member — and with no consent of its own — a copy earns that separately, including the destructive-action acknowledgment. It does inherit production's fixture-recording and concurrent-run settings, so check those two on the copy if they matter to your test. It does not inherit Queued-run patience — a copy falls back to the platform default wait, so set it again on the copy if production uses a custom value. It can still read connected live systems, so staging is not a vendor-data sandbox; and approving a paused supervised test call executes that write for real against those systems rather than simulating it — see Approving a supervised test call. Version history can restore the fields its snapshots capture; production-only wiring and consent remain outside that rollback.

Fixing stale tools

If your plan changed or a connector subscription was cancelled since the automation was configured, some of its allowed tools may no longer exist in your tenant's catalog. In the Capabilities section the tool picker surfaces these as removable unknown chips:

1. Find the tools marked unknown and remove them.
2. A save is refused while any tool in the policy is no longer in your catalog — the error names the offending tools. Remove every chip marked unknown before saving.

Browser drafts and saved versions

The builder keeps a local draft in your browser and auto-saves that draft whenever you edit. It is scoped to your tenant and signed-in user, but it is still only browser storage:

• It is not the configuration the automation runs.
• It does not create a version-history entry.
• It is not shared with another browser or device.
• Discard local draft reloads the saved server configuration.

For a brand-new local draft, Deploy as Dry Run creates the persisted automation and its first immutable version. For an existing automation, a successful versioned-configuration Save normally appends another immutable version—even when you are saving a live automation. The dedicated consent-only fixture-recording update is the exception: it does not append a version. Saving does not return a live automation to dry run. Most saved fields shape later launches; the active-run boundary is detailed below.

Promoting an automation saves pending edits before switching it to live, so more than one snapshot can be appended during the overall operation. Treat version history as a sequence of saved operations, not a one-row-per-button-click change log.

Saving

The builder saves from anywhere. The action bar at the bottom shows the automation's lifecycle status (Draft, Dry run, or Live) and an unsaved changes indicator whenever your edits differ from what is saved.

1. Click Save on the action bar. Client-side checks run first (runtime and credit bounds, at least one callable tool, a valid failure-alert address if alerts are on).
2. On a normal versioned-configuration save, the automation on the server matches your edits and a new immutable version is recorded. A consent-only fixture-recording update uses its dedicated path and does not append a version. A save is never refused because a run is in flight: the running automation keeps the immutable version it pinned at launch, so saving cannot corrupt that run's own snapshot — but the save rewrites the shared MCP client's tool allow-list and dry-run flag, and the gateway re-reads both on every tool call. Wait for an active run to finish—or interrupt it—before widening tools. The snapshot itself covers only its captured fields; knowledge sources and the effective composed prompt are not versioned.
3. On failure the builder shows a specific message. Common support codes:

If your local draft differs from the saved automation, a banner offers Save changes or Discard local draft. The server copy remains the live source until you save.