# Pipelines ## Overview The **pipeline** is what turns your connected **Salesforce orgs** and **GitHub repositories** into a governed **deployment workflow**. It defines the **stages** a change must pass through (from development to production) and the **quality criteria** each stage enforces. Without a **pipeline**, SRE.ai has no structure for how code should move through your **environments** or when a **deployment** should be blocked. Pipelines gives you a **workflow builder** for mapping how code moves from development through production. Each pipeline is rooted in a **repository** and consists of **stages**, each mapped to a **branch** and one or more **Salesforce environments**. {% hint style="info" %} **Pipelines' functionality is informed by best practices for release management.**\ \ [Read SRE.ai's release strategies documentation](/best-practices/release-management-strategies.md) for more information. {% endhint %} ## Core capabilities
### Templates **SRE.ai Pipelines feature offers three preset templates, known as *****release management strategies*****:** * **Release Flow:** Structured, multi-stage promotion with formal QA and a dedicated hotfix path. Best for teams with scheduled release cycles. * **Progressive Flow:** Multi-stage validation with stricter quality gates at each step. Best for teams that need deliberate control over what reaches production. * **Continuous Flow:** Simplified, fast path from development to production. Best for teams practicing continuous delivery with rapid iteration. Templates cannot be edited. Templates consist of stages. {% hint style="info" %} Not sure which template fits your team? Read [SRE.ai's release strategies documentation](/best-practices/release-management-strategies.md) for a side-by-side comparison with real-world examples. {% endhint %}
### Stages **A stage is a highly customizable block that represents a discrete phase in your deployment lifecycle.** {% hint style="success" %} Each stage serves as both a checkpoint and a configuration point, defining which branch it tracks, which Salesforce environments it deploys to, and the quality standards that must be met before changes can proceed. {% endhint %} SRE.ai's Pipelines feature supports five customizable stages: * developer/ team/ project * code integration * staging * production * hotfix The standard Pipelines' progression flows left to right. An example of a Pipelines' flow: * **developer/team/project → code integration → staging → production**.
### Environments **Environments are deployment targets within a stage.** Each environment: * Maps to a **Salesforce org** (your Production org, Sandbox, or Scratch Org) * Tracks **deployment status** and history * Can be **promoted** to parent stage environments ### Salesforce org connections **Salesforce org connections represent your actual Salesforce organizations that SRE.ai deploys to.** SRE.ai supports two types of Salesforce orgs connections: * **Regular Orgs**: * Traditional fixed Salesforce orgs (Production or Sandbox) that can be assigned to specific branches. * **Sandbox Pool Orgs**: * Tied to PRs instead of specific branches. These orgs best serve developer workflows. ## How it works ### Template details Each template creates a fixed stage hierarchy when a pipeline is first configured. The hierarchy determines the only valid promotion path for changes: from child stages up to their parent stage, working toward the root Production stage. Stages form a tree, not a flat list. Changes must move through every level of the tree in order — skipping stages is not permitted. * **Release Flow** * For scheduled releases with formal QA processes
Click to learn more about the Release Flow template {% hint style="success" %} **Best for**: Teams with scheduled release cycles and formal staging processes. {% endhint %} **Stage hierarchy**: Release Flow is the only template with five stages. Production is the root. Staging and Hotfix are both direct children of Production Hotfix is a parallel branch off Production, not a step in the main promotion path. Code Integration sits under Staging, and Developer / Team / Project is the leaf under Code Integration. ``` Production (max 1 environment) ├── Staging (no environment limit) │ └── Code Integration (no environment limit) │ └── Developer / Team / Project (no environment limit) └── Hotfix (max 1 environment) ``` **Stages**: * **Production:** * Root stage * Capped at 1 environment * All main-flow promotions terminate here * **Staging:** * Pre-production validation * No environment cap * Supports multiple orgs (e.g., UAT and SIT in parallel) * Receives promotions from Code Integration. * **Code Integration:** * The first shared integration point * All developer feature work merges here before advancing to Staging * **Developer / Team / Project:** * Leaf stage. * PR-driven sandbox pool allocation. * No fixed branch required. * **Hotfix:** * Emergency fix path * Capped at 1 environment. * Direct child of Production, sibling to Staging * Changes here promote straight to Production and never pass through Staging or Code Integration **Default quality gate settings** (apply to all five stages at creation): * **Code review:** * Enabled, blocking on Critical-severity comments * **Code coverage:** * 75% minimum required to promote * **Pull requests:** * Disabled * **Test level:** * Run Specified Tests These defaults apply uniformly. Teams typically tighten gates on Staging and Production and leave Developer stages lighter. **Promotion paths**: * Main path: * Developer / Team / Project → Code Integration → Staging → Production * Hotfix path: * Hotfix → Production (bypasses Code Integration and Staging entirely)
* **Continuous Flow** * For rapid deployment and continuous delivery
Click to learn more about the Continuous Flow template {% hint style="success" %} **Best for**: Teams practicing continuous deployment with rapid iteration and minimal promotion overhead. {% endhint %} **Stage hierarchy**: Continuous Flow creates three stages. Production is the root. Staging + Integration is its only child, and Developer / Team / Project is the leaf. ``` Production (max 1 environment) └── Staging + Integration (no environment limit) └── Developer / Team / Project (no environment limit) ``` **Stages**: * **Production:** * Root stage. * Capped at 1 environment. * **Staging + Integration:** * Combined integration and pre-production stage. * `code-integration` stage type. * No environment cap. * **Developer / Team / Project:** * Leaf stage. * PR-driven sandbox pool allocation. * No fixed branch required. **Default quality gate settings** (apply to all three stages at creation): * **Code review:** * Enabled, blocking on Critical-severity comments * **Code coverage:** * 75% minimum required to promote * **Pull requests:** * Disabled * **Test level:** * Run Specified Tests **Promotion path**: Developer / Team / Project → Staging + Integration → Production
* **Progressive Flow** * For staged validation with enhanced quality gates
Click to learn more about the Progressive Flow template {% hint style="success" %} **Best for**: Teams that want the simplicity of a three-stage layout but intend to configure stricter quality gates and tighter promotion controls than a pure continuous delivery setup. {% endhint %} **Stage hierarchy**: Progressive Flow creates the same three-stage structure as Continuous Flow. The stage names, types, hierarchy, and default settings are identical at the point of creation. ``` Production (max 1 environment) └── Staging + Integration (no environment limit) └── Developer / Team / Project (no environment limit) ``` **Stages**: * **Production:** * Root stage. * Capped at 1 environment. * **Staging + Integration:** * Combined integration and pre-production stage. * `code-integration` stage type. * No environment cap. * **Developer / Team / Project:** * Leaf stage. * PR-driven sandbox pool allocation. * No fixed branch required. **Default quality gate settings** (apply to all three stages at creation): * **Code review:** * Enabled, blocking on Critical-severity comments * **Code coverage:** * 75% minimum required to promote * **Pull requests:** * Disabled * **Test level:** * Run Specified Tests **Promotion path**: Developer / Team / Project → Staging + Integration → Production
### How branches map to pipeline stages Each stage can be configured to connect to a specific branch in your repository. When you configure a stage, you select which branch it tracks and which Salesforce environment(s) it deploys to. A typical setup might look like this: | Stage | Branch | Environment(s) | | ----------- | ------------- | ---------------------------- | | Development | `develop` | Developer sandboxes | | Integration | `integration` | QA sandbox | | Staging | `staging` | UAT sandbox, SIT environment | | Production | `main` | Production org | You can connect multiple Salesforce orgs to a single branch. As changes move through the pipeline, they can be deployed to one org or several, whichever fits your release process. {% hint style="info" %} **Selecting a branch in a pipeline stage doesn't trigger a deployment on its own.** The branch selection indicates where SRE.ai should look for changes and where to commit metadata. Deployments happen when you explicitly move changes through the pipeline. {% endhint %} ### **Deployment workflow** SRE.ai executes a structured workflow when you initiate a deployment: 1. **Confirm Change**: Verify which change (feature or fix) to deploy 2. **Confirm Target Org**: Auto-detect or select the deployment target based on the stage hierarchy 3. **Check Quality Gates**: Run automated quality checks against stage requirements 4. **Deploy**: Execute deployment to the target Salesforce org if all gates pass 5. **Summarize Issues**: If quality gates fail, provide a detailed issue summary for remediation This workflow ensures that every deployment meets your quality standards before it is deployed to your Salesforce environments. ### Deployment target enforcement SRE.ai enforces that changes move through your pipeline **in order**. The deployment target is determined by the pipeline. {% hint style="info" %} **Example:** If your pipeline is Developer → Integration → Staging → Production, a change that has only reached Integration can only be promoted to Staging next — not directly to Production. {% endhint %} You cannot skip stages or deploy to an out-of-order environment. * The deployment UI only shows the **next valid target** for a given change. Invalid targets are not available. * A change's **first deployment** must always target the lowest stage in the pipeline (e.g., Developer or Code Integration). * Attempting to deploy to an incorrect target returns a clear error. {% hint style="warning" %} Deploying to a Salesforce org that is not mapped to a pipeline stage is not supported through the standard deployment flow. Contact your workspace admin if you need to deploy to an ad-hoc environment. {% endhint %} ## Setup ### Reset and template selection A **Reset** button is available in the **top right corner** of the pipeline workspace. Use it to clear your current pipeline configuration and select a new template. This is useful when starting over or switching release management strategies. {% hint style="danger" %} Resetting a pipeline will remove your current stage configuration. This action cannot be undone. {% endhint %} To confirm the reset, you will be prompted to type the pipeline name before the action proceeds. ### Initial setup Setting up a pipeline requires two steps: 1. Select a repository to connect to
2. Select a template
### Customization All five stages share the same customizable attributes: * Developer/team/project * Code integration * Staging * Production * Hotfix Read below to learn about their customizable attributes

Branch association

Each stage can track a specific Git branch.

Staging might track a "qa" branch while production tracks "main."

The branch indicator appears in the stage card's upper right corner

Environment mapping

The environments section shows which Salesforce orgs receive deployments when changes reach this stage.

You can search existing environments or add new ones. Multiple environments can be mapped to a single stage for scenarios like parallel QA testing.

Quality gates

Each stage enforces its own set of quality criteria that must be satisfied before changes can advance. Configure code review requirements, code coverage thresholds, test levels, and pull request requirements.

Notifications

Each stage can send notifications to email, Teams, or a webhook destination when specific pipeline events occur, such as deployment success, failure, or a new commit.

### Quality gates **Configured at the stage level, quality gates define the criteria that must be satisfied before changes can advance.** {% hint style="success" %} Quality Gates are the governance layer that transforms the Pipeline from a visualization tool into an enforcement mechanism. {% endhint %}
Quality gates are enforced when the user attempts to move changes along the pipeline through chat.
The following gates are configurable per stage:
Click to learn more **Code review** Enable or disable code reviews for the stage. When enabled, set the minimum comment severity required to block a deployment: **Critical**, **High**, or **Medium**. **Code coverage** Require a minimum code coverage threshold before changes can advance. Available thresholds: **75%**, **80%**, **85%**, or **90%**. **Test level** Control which tests run during a deployment to the stage's environments: * **Unspecified:** defer to the org's default test behavior * **No test run:** skip tests entirely * **Run specified tests:** run only the tests you define * **Run local tests:** run all tests defined in your package * **Run all tests in org:** run every test class in the target org When deploying via chat, the test level inherited from the pipeline stage is shown above the component selection so you can confirm the setting before proceeding. {% hint style="warning" %} **No test run is not valid for Production orgs.** If a stage targets a Production org and no specific tests are configured, SRE.ai automatically falls back to **Unspecified** rather than No test run. Passing a No test run to a Production deployment would cause Salesforce to reject it. For non-Production orgs (sandboxes), SRE.ai falls back to **No test run** when no tests are specified. {% endhint %} **Pull requests** Require a pull request to be open before changes can advance to this stage.
### Stage notifications Each stage can send notifications when pipeline events occur.
Click to learn configuration details **Platform** Select where notifications are delivered: * Email * Microsoft Teams * Webhook **Channel** Set the specific channel, address, or endpoint that receives the notifications. **Events** Enable notifications independently for each of the following events: * **Initiated:** a deployment to this stage has started * **Success:** a deployment completed successfully * **Failure:** a deployment failed * **Deployment:** any deployment activity * **Commit:** a new commit was pushed to the tracked branch * **Change:** a new change was detected in the tracked branch * **Test failure:** a test run failed during deployment
### Stage connections Pipeline connections define how changes move between stages.
Click to learn configuration details **Merge type** When changes are promoted, select how they are merged into the target branch: * **Merge:** Standard merge commit * **Squash:** Combine all commits into one before merging * **Rebase:** Rebase commits onto the target branch **Promotion mode** * **Automatic:** Changes are promoted without manual intervention when all gates pass * **Manual:** A user must explicitly trigger the promotion **Pull requests** Require a pull request between stages before changes can advance. **Approvals** Require at least one approval before changes can advance to the next stage.
--- # 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/setting-up-sre.ai/pipelines.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.