# Ticket to deploy
## Overview
A **Change** is SRE.ai's core unit of work — the thing being delivered. A Change can represent a bug, a defect, a task, or a user story. It is the Salesforce work item moving through your pipeline from intake to production.
Delivering a Change involves more than writing code. It moves through design, implementation, code review, testing, deployment, and documentation — across multiple people, tools, and handoffs. Each step takes time. Each handoff creates waiting. When issues surface late in review, or documentation gets skipped, the total time to complete the work grows further.
**The problem ticket to deploy solves is time** — the accumulated time spent across every stage of delivery, and the inconsistent quality that results when that process depends too heavily on a few experienced people.
**The solution is delegation.** When a Change is created and a Jira ticket linked, SRE.ai activates a chain of agents that takes over the delivery work: spec, design, build, code review, test, fix, and deploy. Humans confirm at critical gates. The agents carry the rest.
SRE.ai enables this through four capabilities working together:
* **Agents** handle the delivery chain — design, implementation, code review, and deployment — with human confirmation at each stage.
* **Changes** track the full lifecycle — commits, pull requests, quality findings, test results, and deployments — in a single audit trail.
* **Jira integration** links a ticket to a Change so the agent chain has context when it starts and can close the ticket when the work ships.
* **Automations** close the loop by updating the originating Jira ticket automatically after a successful deployment.
## Agent-driven delivery from ticket to deployed change
### Scenario
**Problem:**
Delivering a Salesforce Change — whether it's a bug, a defect, a task, or a user story — involves a long sequence of steps that pass through multiple hands.
A ticket arrives. Someone designs the solution. A developer builds it. A reviewer checks the code. Issues get found and fixed. The change gets deployed. Documentation gets written. The Jira ticket gets updated. Each stage requires a handoff. Each handoff creates waiting time. When review cycles uncover problems, the sequence restarts and the total time grows.
The sum of that time — across every handoff, every wait, every rework cycle — is what makes Salesforce delivery slow and expensive.
**SRE.ai's fit:**
When a Change is created and assigned in SRE.ai, a chain of agents takes over the delivery work. The Design Agent produces a technical spec. After human approval, the Build Agent implements it, following the repo's existing patterns and committing to a feature branch. The Code Review Agent surfaces issues. If fixes are needed, agents address them. The Deploy Agent ships the change to the target environment.
Humans confirm at the gates that matter — approving the design, reviewing generated code, authorizing deployment — without carrying the work between those gates themselves.
{% hint style="success" %}
This use case relies on SRE.ai's Agents, Changes, and Jira integration features. Read [the Agents documentation](/using-sre.ai/agents.md) for an overview of the Design, Build, and Deploy Agents, [the Changes documentation](/using-sre.ai/changes.md) for how work is tracked, and [the Integrations documentation](/setting-up-sre.ai/integrations.md) for Jira connection setup.
{% endhint %}
### Who this is for
Teams delivering Salesforce Changes who want to reduce the total time from ticket to deployed change — without sacrificing consistency, quality, or traceability.
{% hint style="info" %}
Particularly useful for delivery teams where senior engineers are pulled into every stage of the process to compensate for inconsistent practices. The agent chain produces consistent, reviewable outputs at each stage, so senior review is focused on approvals rather than corrections.
{% endhint %}
Click to learn how SRE.ai addresses this scenario
**What you'll need**
* A connected GitHub repository ([see Integrations documentation](/setting-up-sre.ai/integrations.md))
* At least one connected Salesforce org ([see Salesforce Orgs documentation](/setting-up-sre.ai/salesforce-orgs.md))
* A connected Jira integration, if linking tickets ([see Integrations documentation](/setting-up-sre.ai/integrations.md))
**Workflow**
Agents are activated in natural language from the Command Center. No special commands are required.
**1. Create the Change and link the ticket**
1. Open the **Command Center** and describe the work to be done — the bug, defect, task, or user story.
2. SRE.ai creates a **Change** to track the full delivery lifecycle.
3. In the Change detail view, navigate to the **External Issues** section and link the Jira ticket.
* SRE.ai syncs the ticket's key, summary, and status and displays them alongside the Change.
* The agent chain will use this context when designing and building the solution.
**2. Design phase**
1. SRE.ai activates the **Design Agent**. The agent explores the repository structure, examines relevant metadata in the connected org, and researches best practices for the change type.
2. The Design Agent produces a design document containing:
* Success criteria
* Architecture decisions
* Implementation plan
* Testing strategy
* Risk notes
3. The design document is created with a status of **Draft**. A team member reviews it and sets the status to **Approved** when the approach is confirmed.
* Designs can also be set to **Under Review**, **Implemented**, or **Archived** to reflect their current state.
4. No implementation begins until the design is approved.
**3. Build phase**
1. With an approved design, the **Build Agent** activates from the Command Center.
2. The Build Agent:
* Creates a feature branch from main
* Generates the required code and metadata files, following the repo's existing patterns and naming conventions
* Validates the changes against the connected org
* Commits the result to the feature branch
3. The agent's task is tracked on the linked Change, providing visibility into what was created, which files were modified, and the commit it produced.
**4. Code review and fix phase**
1. SRE.ai runs code analysis on the committed files and surfaces findings in the Change view — covering code quality, security vulnerabilities, performance, and test coverage.
2. Findings are posted as inline comments on the pull request so reviewers see them without leaving the code review.
3. If issues need to be addressed, the **Build Agent** can be invoked to fix identified findings before the change advances.
4. Once findings at or above the blocking severity are resolved, the Change clears the quality gate and can be promoted.
**5. Deploy phase**
1. The **Deploy Agent** handles deployment to the target environment.
2. Before executing, the agent confirms the target and surfaces what will change.
3. The deployment is logged on the Change timeline with a timestamp and result.
4. If an Automation is configured to update the linked Jira ticket on successful deployment, it fires automatically at this point — see the [Automated Jira updates on deployment](#automated-jira-updates-on-deployment) scenario below.
**Result**
The Change moves from ticket to deployed code through an agent-driven chain, with humans confirming the design, the implementation, and the deployment.
Total delivery time falls because agents carry the work between human gates rather than the work sitting idle waiting for the next person to pick it up. Delivery quality improves because every stage — design, build, review, test — produces a consistent, documented output regardless of who initiated the work.
## Automated Jira updates on deployment
### Scenario
**Problem:**
When a Change deploys, someone has to manually update the corresponding Jira ticket — moving it to Done, adding a comment, or recording which environment received it.
This is a routine step, but when it is skipped, the Jira backlog drifts out of sync with what has actually shipped.
**SRE.ai's fit:**
SRE.ai's Automations include an **Update Jira Ticket** step that fires after a successful deployment and updates the linked Jira issue automatically — no manual action required.
{% hint style="success" %}
This use case relies on SRE.ai's Automations feature and the Jira integration. Read [the Automations documentation](/using-sre.ai/automations.md) for an overview of Triggers and Steps, [the Steps customization documentation](/using-sre.ai/automations/steps/steps-customization.md) for the Update Jira Ticket parameter reference, and [the Integrations documentation](/setting-up-sre.ai/integrations.md) for Jira connection setup.
{% endhint %}
### Who this is for
Teams that track Salesforce delivery in Jira and want ticket status to stay accurate without relying on developers to update tickets after deployment.
Click to learn how SRE.ai addresses this scenario
**What you'll need**
* A connected Jira integration ([see Integrations documentation](/setting-up-sre.ai/integrations.md))
* A Pipeline configured with at least one stage mapped to a Salesforce environment ([see Pipelines documentation](/setting-up-sre.ai/pipelines.md))
* Changes with linked Jira issues ([see Changes documentation](/using-sre.ai/changes.md))
**Setup**
Create an Automation that fires when a deployment to a target environment succeeds and updates the linked Jira ticket.
1. Navigate to the **Automations** page and click **New** to open the Automation Builder.
2. Name the Automation descriptively (e.g., "Update Jira on Production Deployment").
3. In the Automation Builder, click the **Trigger** block to open the Trigger panel.
4. Select **Deployment** as the Trigger type and configure the filters:
* Under **Org filter**, select the production org you want to trigger on.
* Under **Status filter**, select **Success**.
* See [the Triggers customization documentation](/using-sre.ai/automations/triggers/triggers-customization.md) for details on each parameter.
5. Add an **Update Jira Ticket** Step and configure which fields to update on the linked issue — for example, setting the status to Done and adding a deployment comment.
* See [the Steps customization documentation](/using-sre.ai/automations/steps/steps-customization.md) for the full parameter reference.
6. Click the **Activation** button to activate the Automation.
**Example workflow**
1. A Change linked to a Jira issue is promoted through the pipeline and deployed to production.
2. SRE.ai detects the successful deployment and triggers the Automation.
3. The **Update Jira Ticket** Step fires, updating the linked issue's status and adding a deployment note.
4. The Jira ticket reflects the shipped state without any manual action from the developer.
**Result**
Jira tickets are updated automatically when a deployment succeeds.
The backlog reflects what has shipped without depending on developers to update tickets after the fact.
---
# 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.sre.ai/use-cases/ticket-to-deploy.md?ask=
```
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.