Pipeline automation
Learn how SRE.ai can be used to facilitate pipeline automation
Overview
Salesforce teams lose time to manual handoffs, waiting for a reviewer to approve, manually triggering a deployment, or tracking down which environment is out of sync.
Pipeline automation is about removing those handoffs by wiring together the events in your pipeline so the right things happen automatically.
SRE.ai addresses this through two features working in combination:
Pipelines define the stages, branches, and quality gates that govern how changes move from development to production.
Automations let you trigger multi-step workflows (deployments, branch merges, notifications) in response to events in your pipeline.
Together, they let you enforce standards automatically and reduce the manual coordination required to ship.
Static code analysis
Scenario
Problem:
A team wants to catch code quality issues, security vulnerabilities, and best practice violations before changes reach production.
Waiting until deployment to discover these problems creates rework and risk.
SRE.ai's fit:
SRE.ai incorporates static code analysis directly into the pull request review process so issues are caught and addressed early.
Static code analysis ties into SRE.ai's quality gates and PR review workflows.
Read the Pipelines documentation for more on configuring quality gates at each stage.
Who this is for
Teams that want to enforce code quality standards during their review process.
Click to learn how SRE.ai addresses this scenario
What you'll need
At least one Pipeline configured with stages (see Pipelines documentation)
A connected GitHub account (see Integrations documentation)
Setup
Configure the Code Review quality gate on each stage where you want static analysis findings enforced.
Navigate to Pipelines and select your active pipeline.
Click on the stage where you want static analysis enforced (typically your code integration or staging stage) to open the Stage Details panel.
Under Quality gates, toggle Enable Code Review on.
Under Block Review Comments, select the minimum finding severity that should block a change from advancing:
Critical: only the most severe findings block promotion.
High: critical and high-severity findings block promotion.
Medium: critical, high, and medium severity findings block promotion.
See the Pipelines documentation for the full list of quality gate options.
Repeat for any additional stages where you want analysis enforced. Teams typically set a higher severity threshold (less strict) in early stages and a lower threshold (more strict) as changes approach production.
Verify that your GitHub integration is active and that the repository is connected.
Navigate to Integrations and confirm GitHub shows a connected status.
See the Integrations documentation for setup steps if needed.
Example workflow
A developer commits changes, and SRE.ai detects the change in the connected repository.
SRE.ai scans the changed components for code quality issues, security vulnerabilities, and best practice violations.
Findings are surfaced in the change detail view, organized by severity. Developers can search for violations, review finding details, and dismiss findings with a recorded reason.
If the Enable Code Review gate is active for the target stage, the change's quality gate status reflects whether unresolved findings at or above the configured Block Review Comments severity are present.
Developers address flagged findings before advancing the change to the next stage.
Once no findings remain at or above the blocking severity, the change clears the gate and can advance.
Result
Code quality issues are identified and resolved before deployment rather than discovered after.
Changes that pass through this workflow meet the team's quality standards before they advance to staging or production, reducing rework and failed deployments.
Back propagation
Scenario
Problem:
A hotfix is deployed directly to production to resolve a critical issue.
Now the team needs those changes to flow back to lower environments so development and staging don't drift out of sync.
Without back-propagation, teams risk building on outdated code or reintroducing the bug that the hotfix resolved.
SRE.ai's fit:
SRE.ai's Pipeline feature supports backpropagation workflows that automatically push changes from higher environments down to lower ones.
Back propagation is closely tied to how pipeline stages and hotfix branches are configured.
Read the Pipelines documentation and Release management strategies documentation for more on stage hierarchies and hotfix workflows.
Who this is for
Teams that deploy hotfixes directly to production need a reliable way to ensure those changes are reflected across all lower environments without manually cherry-picking commits or coordinating branch merges across the team.
Click to learn how SRE.ai addresses this scenario
What you'll need
A Pipeline configured with a hotfix stage connected to production (see Pipelines documentation)
At least two additional stages representing lower environments (e.g., staging, development)
Automations configured to trigger on deployment events (see Automations documentation)
Setup
Back propagation requires an Automation that triggers after a hotfix deployment and merges the changes into your lower-environment branches.
Navigate to the Automations page and click New to create a new Automation.
Name the Automation descriptively (e.g., "Back Propagate Hotfixes to Staging + Dev").
In the Automation Builder, click the Trigger block to open the Trigger panel.
Select Deployment as the Trigger type and configure the filters:
Under the Org filter, select your production org. This scopes the trigger to deployments targeting production only.
Under the Status filter, select Success. This ensures the automation fires only after a successful deployment, not on failures.
See the Triggers customization documentation for details on each parameter.
The Deployment trigger fires for all successful deployments to the selected org, not only hotfix deployments.
If your team also deploys to production through the standard pipeline, the back-propagation automation will run for those deployments.
This is typically safe, but worth confirming against your team's workflow.
Add a Commit Change Step to merge the hotfix changes into your staging branch. Configure it with the following parameters:
Repository: Select the repository connected to your pipeline
Branch: Select your staging branch
See the Steps customization documentation for details on each parameter.
Add a second Commit Change Step to merge the hotfix changes into your development branch, configured the same way but targeting the development branch.
Optionally, add a Send Teams Message Step to notify your team that backpropagation has completed and to confirm which branches received the changes.
Click the Activation button to activate the Automation.
Consider configuring this Automation alongside your hotfix stage setup, so it's ready the first time a hotfix needs to be deployed.
See the Hotfix strategy use case for the full walkthrough of the hotfix configuration.
Workflow
A hotfix is deployed directly to the production environment through the hotfix stage.
Once the hotfix lands in production, SRE.ai triggers an automation to initiate back-propagation.
The automation automatically merges the hotfix changes into the staging and development branches.
Each lower environment receives the changes, ensuring parity across the full pipeline without manual cherry-picking.
Back propagation is logged on the Changes page, providing a clear audit trail of what was propagated and when.
Result
All lower environments (staging, development, and any other configured stages) now include the hotfix changes.
The team can continue building on branches that reflect the current production state, eliminating drift and preventing the reintroduction of resolved issues.
Hotfix strategy
Scenario
Problem:
A critical bug has been discovered in production.
The team needs an expedited path to deploy a fix without going through the full development pipeline, while still maintaining governance, visibility, and an audit trail.
SRE.ai's fit:
SRE.ai's Pipeline feature includes a dedicated hotfix stage that branches off from staging and connects directly to production, providing a governed fast path for emergency fixes.
The hotfix stage is available in the Release Flow pipeline template. Read the Pipelines documentation for configuration details and the Release management strategies documentation for context on how hotfix stages fit into the broader release process.
Who this is for
Teams that need to ship emergency fixes to production quickly while maintaining quality controls and traceability
Click to learn how SRE.ai addresses this scenario
What you'll need
A Pipeline configured using the Release Flow template, which includes a hotfix stage (see Pipelines documentation)
At least one production environment mapped to the production stage
Quality gates configured for the hotfix stage can be set differently from those in other stages to balance speed with safety.
Optionally, an Automation configured to trigger back propagation after the hotfix deploys (see the Back propagation use case)
Setup
The hotfix stage is included in the Release Flow pipeline template, but you need to configure its environment mapping and quality gates before it's ready to use.
Navigate to Pipelines and select your Release Flow pipeline.
Click on the Hotfix stage to open the Stage Details panel.
Under Environment mapping, click Add Environment, then select the Salesforce org you want hotfixes deployed to. This is typically the same production org mapped to your production stage.
A green checkmark confirms the connection is validated.
Under Quality gates, configure the checks required for hotfix deployments. These can be set differently from your standard pipeline stages to balance speed with safety. Consider:
A lower test coverage threshold than your staging or production gates
Keeping static analysis requirements enabled to catch critical issues
Requiring at least one approval
See the Pipelines documentation for more on quality gate configuration.
Optionally, configure a backpropagation automation to propagate hotfix changes to lower environments after deployment. This prevents drift between production and your development/staging branches.
Navigate to Automations, create a new Automation, and configure a Deployment trigger that listens for deployments to the hotfix stage.
Add Steps to merge the hotfix into your staging and development branches.
See the Back propagation use case for a full walkthrough.
Quality gates on the hotfix stage should reflect your team's minimum acceptable checks for emergency deployments. You can always tighten them later as your hotfix process matures.
Workflow
The team identifies a critical bug in production that requires an immediate fix.
A developer creates a hotfix branch that originates from the hotfix stage in the pipeline, branches off staging, and connects directly to production.
The developer implements the fix and commits to the hotfix branch.
The hotfix passes through the quality gates configured for the hotfix stage. These gates can be scoped differently from the standard pipeline stages to prioritize speed while still enforcing essential checks.
Once quality gates pass, the fix is deployed directly to production through the hotfix stage, bypassing the standard promotion path.
The deployment is tracked in the Changes page and Command Center, maintaining a full audit trail.
Optionally, a back propagation automation merges the hotfix changes into lower environments to maintain parity across the pipeline.
Result
The critical fix is live in production without the delay of a full pipeline promotion.
Quality gates ensured the fix met the team's minimum safety standards even on the expedited path.
The hotfix is fully tracked on the Changes page, and if backpropagation is configured, lower environments are automatically updated to reflect the fix, preventing drift and ensuring the bug isn't reintroduced in future deployments.
Last updated