- Telecommunications
- Salesforce DevOps
- Copado CI/CD
Salesforce DevOps for a US Telecom Provider with Daily Copado Deployments
How BEEU TECH helped a US-based telecommunications provider deploy Salesforce changes every day, move its Copado pipeline to Source format and cut merge conflicts through an embedded Salesforce DevOps engineer.
- DailyDeployments through Copado CI/CD
- 20–30%Less time spent on code reviews
- 25–30Production release cycles supported
Our actual experience delivering great tech and talent.
Engagement overview
- Industry
- Telecommunications
- Client location
- United States
- Engagement model
- Embedded Salesforce DevOps engineer
- Duration
- More than 2 years
- Technologies
- Salesforce, Copado, Git, Jira, Apex, LWC, OmniStudio
- Engagement status
- Ongoing
1. The client
Our client is a US-based telecommunications provider offering high-speed internet, voice and TV services across urban, suburban and rural markets.
Its Salesforce org spans several clouds and business domains: Sales Cloud, Service Cloud, Field Service Lightning and OmniStudio. It mainly runs internal CRM operations, with integrations that reach the customer portal and billing-related flows.
With so many teams and components releasing through one org, the way changes were stored and promoted had started to slow delivery down.
2. The challenge
A metadata pipeline where small changes caused big conflicts
The client deployed to Salesforce every day through Copado, with user stories reaching production every two weeks. Changes were managed in Copado's Metadata format.
In large XML files such as profiles, permission sets and flows, even small changes caused merge conflicts. Tightly coupled metadata meant promotions could pull in dependencies nobody intended to ship.
Four problems kept recurring.
Frequent merge conflicts
Parallel user stories collided in large XML files like profiles, permission sets and flows, even when each change was small.
Deployment failures
Tightly coupled metadata pulled unintended dependencies into promotions, raising the rate of failed deployments.
Slow promotions and validations
Promotion and validation took longer, particularly when several user stories were promoted in parallel.
Issues found mid-release
Some problems sat in the platforms themselves and needed support cases with Copado or Salesforce to resolve.
The client needed more than deployment support. It needed an engineer who could keep daily releases moving while changing how metadata was stored, reviewed and promoted.
3. The solution
Moving the Copado pipeline from Metadata to Source format
BEEU TECH deployed a Salesforce DevOps engineer who works inside the client's release process, across development, deployment, validation and release support.
The central change was the move from Copado's Metadata format to Source format, with Git for version control and Jira tracking every work item through the Copado pipeline.
Six pillars of the release practice
-
Salesforce configuration and backend logic
Built and deployed Apex classes and triggers, Lightning Web Components, flows and OmniStudio artifacts such as OmniScripts, DataRaptors and Integration Procedures.
-
Source format migration
Moved the pipeline from Copado's Metadata format to Source format, so changes to profiles, permission sets and flows conflicted far less often.
-
Daily CI/CD deployments
Ran daily deployments through Copado CI/CD pipelines, covering code, flows, OmniStudio components, integrations and security configuration.
-
Jira-linked user stories
Tracked the work items users raised in Jira, integrated with the Copado pipeline, so each change could be followed from request to release.
-
Automated testing
Tested changes with Copado Robotic Testing as part of the release process.
-
Release and platform support
Supported user stories through to production every two weeks, and resolved issues found mid-release by opening support cases with Copado or Salesforce.
4. The engineering team
BEEU TECH placed a Salesforce DevOps engineer in the client's release team, working on the changes its users raise.
-
Salesforce DevOps Engineer
Develops and deploys Salesforce changes, manages promotions in Copado, validates releases and supports user stories through to production.
The same engineer has stayed with the program for more than two years, carrying knowledge of the org, its pipeline and its release history from one cycle to the next.
5. The release journey
How a change reaches production
Every change follows the same path, from a user story in Jira to a production release every two weeks.
-
Step 1
A user story in Jira
Work raised by users is logged in Jira, which is integrated with the Copado pipeline, so each change carries its story with it.
-
Step 2
Built and committed in Source format
The change is built in Salesforce, whether Apex, Lightning Web Components, flows or OmniStudio, and committed to Git in Source format, which keeps reviews clearer and conflicts fewer.
-
Step 3
Deployed and validated daily
Copado deploys and validates changes every day, with Copado Robotic Testing checking them along the way.
-
Step 4
Released to production every two weeks
Validated user stories reach production every two weeks. When an issue surfaces mid-release, the engineer resolves it, opening support cases with Copado or Salesforce where needed.
6. The business impact
Fewer conflicts, faster reviews and steadier releases
Moving to Source format made the daily pipeline easier to work in, for the engineer and for everyone reviewing changes.
Changes move through Copado CI/CD pipelines every day, across every cloud in the org.
With changes stored in Source format, code reviews became clearer and faster.
Supported across development, deployment, validation and release support.
Before and after the move to Source format
| Before | After |
|---|---|
| Frequent merge conflicts in profiles, permission sets and flows | Merge conflicts reduced significantly |
| Unintended metadata pulled into promotions | Noticeably fewer failures from unintended metadata |
| Slower, less clear code reviews | Clearer code reviews, 20–30% faster |
| Harder debugging and rollbacks | Easier debugging and rollbacks |
7. Long-term value
A release practice the team can keep building on
Source format changed more than the file layout. It made each change easier to review, trace and roll back, which matters most in an org where several clouds and teams release together.
With work tracked in Jira, versioned in Git and promoted through Copado, the history of every release is there for anyone who joins the team.
The engagement shows how one embedded specialist, kept on a program over years, can make a busy Salesforce release practice steadier and easier to work in.
8. Technology stack
- SalesforceSales, Service and Field Service clouds
- OmniStudio (Vlocity)OmniScripts, DataRaptors, Integration Procedures
- CopadoDevOps and CI/CD pipelines
- GitVersion control
- JiraWork item and release tracking
- Copado Robotic TestingTest automation
9. Engineer perspective
“Merge conflicts reduced significantly (especially for profiles/flows), review time reduced by 20–30% and deployment failures caused by unintended metadata were noticeably lower.”
BEEU TECH · ENTERPRISE TALENT
Salesforce DevOps expertise, inside your release team.
Running a busy Salesforce org across several clouds? BEEU TECH places Salesforce DevOps engineers inside your release process to keep deployments moving and make each one safer.
Build the release team your Salesforce org needs.
