# Promote to Production

Before you turn on a schedule or trigger and hand an assignment 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 Jobs have run without unexpected failures.
* HITL approval gates have been exercised — you have seen real approval requests, denied one, and confirmed the assignment handles denial gracefully.
* Edge cases identified during testing have been handled in the SOP or accepted as known gaps.
* The run debugger shows no unexplained errors in recent Jobs.

See [Guardrails for High-Risk Automations](/security/high-risk-guardrails.md) for risk scoring and shadow-mode testing guidance before going live with high-stakes assignments.

### Connections scoped to production Logins

* All connections in the assignment point to production accounts, not personal or sandbox accounts.
* Logins and Secrets used by the assignment 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 assignment 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 Job is acceptable for the expected Job frequency.
* Typical Job 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 assignment in production.
* That person knows they are the owner and understands what the assignment 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 [Assignment Versions](/advanced/assignment-versions.md).
* 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 assignment.
2. Click the **Schedule** button (or calendar icon) in the assignment header.
3. Set the frequency. See [Scheduling Assignments](/assignment-features/scheduling-assignments.md) for all options.
4. Click **Add schedule** to save.

The assignment now runs automatically. Scheduled Jobs appear in the Jobs list with a clock icon so you can distinguish them from manual runs.

### Turning on a trigger

1. Open the assignment.
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](/assignment-features/event-driven-triggers.md) 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 SOP to limit how many records or actions the assignment processes per Job. Once you are confident it is behaving correctly, remove the cap.

```
Process at most 10 records per Job 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 assignment 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 assignment immediately:

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

***

## Sharing Access with Your Team

### Roles required

| What the person does                         | Minimum role needed                      |
| -------------------------------------------- | ---------------------------------------- |
| Builds and edits the assignment              | Builder (for own assignments) or Manager |
| Reviews and approves HITL requests           | Member                                   |
| Monitors own Job results                     | Member                                   |
| Views all team Job results and Team Insights | Administrator                            |
| Changes the assignment SOP or schedule       | Manager or higher                        |
| Manages team members and permissions         | Administrator or higher                  |

See [Roles and Permissions](/teams/roles-and-permissions.md) for the full permissions matrix.

### Memory scope decisions

If the assignment uses [Assignment Memory](/assignment-features/assignment-memory.md), decide before going live whether memory should be per-user or shared across the team:

* **Per-user memory**: Each person who runs the assignment starts from their own memory context. Best for personal productivity assignments 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 assignment.

Changing memory scope after an assignment 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 assignment must be accessible when the assignment runs — not locked to a personal account.
* If operators will trigger the assignment manually, confirm they can see the assignment in their workspace.
* If the assignment 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 assignment — but did not build it — need a short handoff. Cover:

1. What the assignment does and what triggers it.
2. Where to find Jobs and how to read the status indicators.
3. How to respond to HITL requests in the [Activity Inbox](/assignment-features/activity-inbox.md).
4. Who to contact if something looks wrong.
5. How to pause the assignment 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 assignment 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 SOP to create a HITL request if the Job fails, so the owner sees it in the Activity Inbox.

Add the notification step directly to the SOP so it runs automatically.

### Runbook template

Copy and fill in this template before the assignment goes live. Keep it somewhere the whole team can find it.

```
Assignment: [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 Job to identify which step failed.
2. If a Connection is down, check the third-party service status page.
3. If the SOP logic failed, revert to the previous revision via Assignment Versions.
4. Notify [stakeholder] if more than [N] Jobs 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 Jobs manually.
```

***

## Assigning Owners

Every production assignment 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

| Role              | Responsibility                                                                                                         |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Build owner**   | Responsible for the SOP, connections, and making changes. Usually the Builder or Manager who created the assignment.   |
| **Ops owner**     | Responsible for day-to-day monitoring, HITL responses, and escalation. May be a different person from the build owner. |
| **HITL operator** | Handles 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 assignment 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 assignment.

The "owner of last resort" pattern: designate one Administrator who can take emergency action on any assignment 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 assignment's SOP and known edge cases.
4. Have the new owner run at least one manual Job before the next scheduled run.

***

## What's Next?

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

* [Test Safely Before Going Live](/getting-started/test-safely.md) — The testing checklist and environment separation patterns that feed into this guide
* [Guardrails for High-Risk Automations](/security/high-risk-guardrails.md) — Apply the right controls before enabling autonomous write operations
* [Assignment Versions](/advanced/assignment-versions.md) — How to review and revert to a previous revision
* [Designing Human-in-the-Loop Workflows](/assignment-features/hitl-design.md) — Risk tiers, approval shapes, and escalation chains
* [Activity Inbox](/assignment-features/activity-inbox.md) — Where HITL requests land and how to respond
* [Team Insights](/analytics/team-insights-overview.md) — Run volume, failure rates, and cost trends across your team


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.duvo.ai/getting-started/promote-to-production.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.