Salesforce is the bridge that connects end-users and developers, including citizen developers, which make up a large portion of Salesforce’s developers. This explosion of Trailblazers have bypassed the challenges of traditional application development and led to the creation of millions of Salesforce applications over the last fifteen years.
Naturally, there are limitations to application development because of the intricacies of complexity and talent. Because of this, the Salesforce realm has begun borrowing from DevOps practices pioneered by IT teams.
To get to the root of best practices, challenges, and accomplishments of teams dealing with these complexities, Copado recently released it’s second annual TheState of Salesforce DevOps Report, executed and analyzed by Beagle Research. Copado sought to find out how teams innovating on the Salesforce platform can benchmark themselves against other players in the industry.
The key finding: speed > quality
This was a pivotal year in digital transformations. The last 12 months were tumultuous, and this report can give key insights for opportunities to improve and meet new goals for 2021. One of the major findings of this report is that digital transformation accelerated and software delivery teams moved faster in 2020 but at the expense of quality.
The report borrows methods used by the State of DevOps Reports led by DevOps Research and Assessment over the last seven years to understand the unique state and challenges of Salesforce development teams.
Adopting key principles from the long-standing and widely regardedAccelerate State of DevOps Report, Copado and Beagle analyzed performance across Salesforce teams in terms of the dual goals of innovation velocity and release quality and security. More than 230 executives, managers, and members of Salesforce delivery teams were surveyed in Q4 2020. Here’s a good rundown of interesting findings:Read the rest of this entry!
Once upon a time, Salesforce was a simple customer relationship management (CRM) tool that could be easily managed by a single person or a small team. But that time is well in the past.
Today, enterprises are transforming Salesforce into a single source of truth for the whole business and the lifeblood of the modern organization. Salesforce’s low-code software approach (clicks, not code) has opened the door for more teams and skill sets to configure on the platform, meaning businesses can realize faster time-to-value of new tools and features developed with point-and-click tools instead of writing code for maximum business agility and efficiency.
However, like all paradigm shifts, this low-code revolution doesn’t happen without a few stumbles. Standards, methodologies, and tools for code-based development have evolved over decades of software development. But declarative-first platforms, like Salesforce, are shifting the onus of managing app updates and new feature releases to configs made by Salesforce administrators and operations teams. In many cases, the concepts of development may be equally applicable to configs- and code-based changes, the traditional tools have not kept pace. One example of this is the concept of deployments.
What is deployment?
Deployment is simply the process of releasing new functionality to users. Most Salesforce admin’s introduction to deployments is through building Change Sets. Low-code super users and admins also need to consider how they will move their config changes through the release path to production, which may not be possible with Change Sets.
It’s these config-based changes that can present a host of potential deployment issues, as teams battle to release updates quickly in the name of speed and agility, without exposing their entire organization to the possibility of unintended consequences from poorly managed releases.
Deployment issues can become big problems
Like all core enterprise systems, Salesforce isn’t an island unto itself. That is, other apps and systems depend on Salesforce data being current and complete, and failing to account for dependencies when modifying or updating Salesforce apps can create a number of new challenges that Salesforce admins may not be well-equipped to handle.
Loss or corruption of relational data
Salesforce’s relational database structure allows users to relate objects to share information between objects. But those data relationships can easily be broken by poor data hygiene practices, modifying records and configuration settings, or accidentally deleting large volumes of data.
Worse, as more teams across the businessadd or request more apps, it increases the probability of misconfiguration because any little change or mistake can have a massive negative impact. For example, an inadvertent change to a discount rule may cause quotes to miscalculate or a miskeyed field accidentally reassigns sales accounts to an inactive user.
In either case, remedying broken data relationships for such important basic functions is time-consuming and labor-intensive, as admins have to manually scour change histories (if they tracked them) and rectify whatever errors they’re able to find — all while business users eagerly await the restoration of critical functionality.
Duplicate data between Salesforce orgs
While data relationship loss is a big concern, duplicate data can also have a significant and unpleasant impact on everyday activities often compounding relational data issues. Read the rest of this entry!