Promote to Production

​

Pre-Promotion Checklist

​

Testing signed off

• At least three end-to-end test Runs have run without unexpected failures.
• HITL approval gates have been exercised — you have seen real approval requests, denied one, and confirmed the agent handles denial gracefully.
• Edge cases identified during testing have been handled in the AOP or accepted as known gaps.
• The run debugger shows no unexplained errors in recent Runs.

​

Connections scoped to production Logins

• All connections in the agent point to production accounts, not personal or sandbox accounts.
• Logins and Secrets used by the agent belong to a service account or shared Login where appropriate — not a personal user account that could be disabled.
• Connection permissions are scoped to the minimum required. An agent that only reads data from Salesforce does not need write permissions.

​

Human-in-the-Loop coverage validated

• Every action that is irreversible, expensive, or externally visible has an approval gate.
• Approval descriptions give reviewers enough context to decide without opening another system.
• Escalation paths are defined: what happens if a request is ignored for 24 hours, or denied twice.

​

Cost and latency within target

• Estimated cost per Run is acceptable for the expected Run frequency.
• Typical Run duration fits within the business process SLA (for example, a nightly report that takes four hours is a problem if stakeholders expect it before 08:00).
• If cost or duration is higher than expected, investigate before going live rather than hoping it improves.

​

Owner and escalation contact named

• One named person is responsible for this agent in production.
• That person knows they are the owner and understands what the agent does.
• A backup contact is identified for when the primary owner is unavailable.

​

Rollback path documented

• The previous working revision is identified and accessible via Agent Versions.
• The team knows how to pause the schedule or trigger — and who is allowed to do it.

​

Switching On the Trigger or Schedule

​

Soft-launch options

Process at most 10 records per Run for the first two weeks.
Log a message if the cap is reached: "Volume cap active — [count] records processed."

Only perform write actions between 08:00 and 18:00 Monday–Friday.
Outside these hours, queue the action and process it at 08:00 on the next business day.

​

Toggling off in seconds

• Disable a schedule: Open the agent, go to Schedule, and toggle the schedule off. Runs already running continue to completion; no new Runs start.
• Disable a trigger: Open the agent, go to Triggers, and disable the trigger. No new Runs are created from that trigger.
• Revoke a connection: Go to the Connections page, find the connection, and disconnect it. The agent fails immediately if it tries to use that connection — the fastest way to stop a write-heavy agent when you are not sure whether damage is still occurring.

​

Sharing Access with Your Team

​

Roles required

​

Memory scope decisions

• Per-user memory: Each person who runs the agent starts from their own memory context. Best for personal productivity agents where each user’s context is independent.
• Shared memory: All runs read from and write to the same memory context. Best for team workflows where state needs to persist across different users triggering the agent.

​

Logins and Secrets access

• Logins and Secrets used by the agent must be accessible when the agent runs — not locked to a personal account.
• If operators will trigger the agent manually, confirm they can see the agent in their workspace.
• If the agent uses a login stored in your personal vault, consider moving it to a shared or service Login before going live.

​

Onboarding operators

​

Notifications and Runbook

​

Where alerts go

• Slack: Have the agent post a summary to a team channel after each run.
• Email: Use a Gmail or Outlook connection to send a status email to the owner.
• HITL escalation: Set a fallback in the AOP to create a HITL request if the Run fails, so the owner sees it in Requests.

​

Runbook template

Agent: [Name]
Owner: [Name, contact]
Backup contact: [Name, contact]
What it does: [One sentence]
Runs: [Frequency or trigger]
Typical duration: [e.g., 5–10 minutes]
Typical cost per run: [e.g., $0.08]

Failure response:
1. Check the run debugger for the failed Run to identify which step failed.
2. If a Connection is down, check the third-party service status page.
3. If the AOP logic failed, revert to the previous revision via Agent Versions.
4. Notify [stakeholder] if more than [N] Runs fail in a 24-hour window.

Pause procedure:
1. Open the assignment.
2. Disable the schedule or trigger.
3. Notify [Slack channel / email list] with a brief explanation.

Rollback procedure:
1. Open the assignment.
2. Go to the revision selector in the builder toolbar.
3. Select the last known-good revision.
4. Re-enable the schedule or trigger.
5. Monitor the next two Runs manually.

​

Assigning Owners

​

Owner types

​

Escalation when the owner is unavailable

1. Primary owner — first contact for any issue.
2. Backup owner — covers when the primary is OOO. Must have at least Manager role.
3. Escalation Manager — for issues the backup cannot resolve. Has permission to pause, revert, or disable the agent.

​

When ownership changes

​

What’s Next?