Skip to main content
Before you turn on a schedule or trigger and hand an agent over to your team, run through this guide. It covers the decisions and steps that builders most often skip — and regret later.

​
Pre-Promotion Checklist

Work through this list before enabling any schedule or trigger. Each item represents a category of surprise that commonly appears in the first week of production use.

​
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.
See Guardrails for High-Risk Automations for risk scoring and shadow-mode testing guidance before going live with high-stakes agents.

​
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

Enable the schedule or trigger only after the checklist above is complete.

​
Turning on a schedule

  1. Open the agent.
  2. Click the Schedule button (or calendar icon) in the agent header.
  3. Set the frequency. See Scheduling Agents for all options.
  4. Click Add schedule to save.
The agent now runs automatically. Scheduled Runs appear in the Runs list with a clock icon so you can distinguish them from manual runs.

​
Turning on a trigger

  1. Open the agent.
  2. Click the Schedule button and select the Triggers tab (lightning bolt icon).
  3. Configure the trigger source — email, Slack message, file drop, status change, or webhook.
  4. Save the trigger.
See Event-Driven Triggers for setup details by trigger type.

​
Soft-launch options

Running at full volume immediately is rarely the right move. Consider these options for the first days of production: Volume cap — Add an explicit cap to the AOP to limit how many records or actions the agent processes per Run. Once you are confident it is behaving correctly, remove the cap. 
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."
Time-window restriction — Limit write operations to business hours so a human can respond quickly if something goes wrong. 
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.
Restricted source — If the agent handles inbound events (emails, Slack messages, file drops), configure the trigger to accept events from one team or channel before expanding to all.

​
Toggling off in seconds

If something goes wrong, you can stop the agent immediately:
  • 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

What the person doesMinimum role needed
Builds and edits the agentBuilder (for own agents) or Manager
Reviews and approves HITL requestsMember
Monitors own Run resultsMember
Views all team Run results and Team InsightsAdministrator
Changes the agent AOP or scheduleManager or higher
Manages team members and permissionsAdministrator or higher
See Roles and Permissions for the full permissions matrix.

​
Memory scope decisions

If the agent uses Agent Memory, decide before going live whether memory should be per-user or shared across the team:
  • 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.
Changing memory scope after an agent has been running in production can cause unexpected behavior. Make this decision before the first production run.

​
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

The people who will trigger and monitor the agent — but did not build it — need a short handoff. Cover:
  1. What the agent does and what triggers it.
  2. Where to find Runs and how to read the status indicators.
  3. How to respond to HITL requests in the Activity Inbox.
  4. Who to contact if something looks wrong.
  5. How to pause the agent in an emergency (see above).

​
Notifications and Runbook

​
Where alerts go

Configure at least one notification path before going live. Options include:
  • 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 the Activity Inbox.
Add the notification step directly to the AOP so it runs automatically.

​
Runbook template

Copy and fill in this template before the agent goes live. Keep it somewhere the whole team can find it. 
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

Every production agent needs a named owner. Ownership is not the same as the team role — it is an informal accountability designation that complements the permissions model.

​
Owner types

RoleResponsibility
Build ownerResponsible for the AOP, connections, and making changes. Usually the Builder or Manager who created the agent.
Ops ownerResponsible for day-to-day monitoring, HITL responses, and escalation. This may be a different person from the build owner.
HITL operatorHandles approval requests in the Activity Inbox. There can be multiple operators covering different time zones.

​
Escalation when the owner is unavailable

Define the escalation path before the agent goes live:
  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.
The “owner of last resort” pattern: designate one Administrator who can take emergency action on any agent regardless of who built it. This person does not need to be involved day to day — they exist so there is always someone who can act.

​
When ownership changes

When the build owner changes roles or leaves the team:
  1. Transfer the relevant Logins and Secrets to the new owner’s access or to a shared Login.
  2. Update the runbook with the new owner’s contact details.
  3. Schedule a handoff session so the new owner understands the agent’s AOP and known edge cases.
  4. Have the new owner run at least one manual Run before the next scheduled run.

​
What’s Next?

Your agent is live. The first week is the highest-risk period — monitor it closely before settling into a routine cadence.