Pipelines
Learn about SRE.ai's Pipelines feature
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.
Pipelines' functionality is informed by best practices for release management. Read SRE.ai's release strategies documentation for more information.
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.
Not sure which template fits your team?
Read SRE.ai's release strategies documentation for a side-by-side comparison with real-world examples.
Stages
A stage is a highly customizable block that represents a discrete phase in your deployment lifecycle.
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.
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
Best for: Teams with scheduled release cycles and formal staging processes.
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.
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
Best for: Teams practicing continuous deployment with rapid iteration and minimal promotion overhead.
Stage hierarchy:
Continuous Flow creates three stages.
Production is the root.
Staging + Integration is its only child, and Developer / Team / Project is the leaf.
Stages:
Production:
Root stage.
Capped at 1 environment.
Staging + Integration:
Combined integration and pre-production stage.
code-integrationstage 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
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.
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.
Stages:
Production:
Root stage.
Capped at 1 environment.
Staging + Integration:
Combined integration and pre-production stage.
code-integrationstage 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:
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.
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.
Deployment workflow
SRE.ai executes a structured workflow when you initiate a deployment:
Confirm Change: Verify which change (feature or fix) to deploy
Confirm Target Org: Auto-detect or select the deployment target based on the stage hierarchy
Check Quality Gates: Run automated quality checks against stage requirements
Deploy: Execute deployment to the target Salesforce org if all gates pass
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.
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.
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.
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.
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.
Resetting a pipeline will remove your current stage configuration. This action cannot be undone.
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:
Select a repository to connect to
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.
Quality Gates are the governance layer that transforms the Pipeline from a visualization tool into an enforcement mechanism.
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.
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.
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.
Last updated