Tag Archives: salesforce devops

An vector diagram depicting running a Salesforce CPQ deployment
Data Deployment, Salesforce CPQ, Salesforce DevOps

How to Run a Salesforce CPQ Deployment

Leave a comment

Learn how to easily run a Salesforce CPQ deployment using Prodly’s automation templates. Deploy CPQ records in 80 percent less time than manual deployment—while simultaneously eliminating errors.

Automate Salesforce CPQ Deployments

Few of us get excited about tedious manual labor. That’s why Prodly created the first DevOps tool for Salesforce CPQ to automate what is otherwise hours of manual, error-prone work. 

Here’s how to easily run a Salesforce CPQ deployment with Prodly’s automation:

  1. Select where the ready-to-go changes are and where they need to go—whether that’s the next org in your release path or a branch in your repository.
  2. Select whether all of CPQ needs to be deployed or just a part of CPQ (i.e. all Price Rules or a new Product)
  3. Deploy.

Prodly’s Salesforce CPQ Automation Features

Proven Templates for the Entire CPQ Configuration Data Model

Prodly DevOps comes with data set templates—think prebuilt automations—that capture the entirety of the Salesforce CPQ configuration data model. That means you can be up and running in no time. Our templates have been battle tested on over 55 million CPQ deployments.

All you have to do is make your CPQ changes in your development org, select the appropriate template—and Prodly DevOps does the rest for you. It knows all the parent-child relationships and selects them automatically for deployment. You can even deploy the entire CPQ configuration in one click using our automation templates.

Customize Data Set Templates

If you like, you can even customize data set templates to add additional relationships with configuration data.

By going deeper into the data set templates, you can get really granular as to what you want to deploy and what not. Then you can preview the deployment to make sure it has everything you need in it—and nothing else.

Temporarily Deactivate Platform Events in Salesforce

Many of our customers say their favorite feature in Prodly DevOps is the ability to temporarily deactivate—and, importantly, reactivate—platform events and automations like Validation Rules and Flows during a deployment.

While great for running your business and maintaining data hygiene in your org, these events can cause unnecessary and frustrating deployment errors during the development process. Prodly DevOps automatically reactivates the events when the deployment is completed.

Prodly’s ability to automate this during a deployment saves you heaps of time compared to manually turning events on and off. Plus, it ensures you don’t overlook an event—which could have serious consequences.

For example, if you forget to reactivate a Validation Rule, it could result in bad data being entered into the system. Or if you forget to reactivate a Flow, it could mean that a critical part of a business workflow doesn’t get executed.

Progress Report

Prodly DevOps shows you in the UI how the deployment is progressing, and it sends you an email notification when it’s complete. That way, you don’t have to keep an eye on it yourself.

Audit History

Does governance and SOX compliance keep you or your management up at night? Prodly DevOps provides automatic change tracking that provides an audit report of every change. This easily-generated audit report includes who made what changes, when, and why—and it can easily be sent, too. Your next SOX audit will fly by.

Promoting CPQ Configuration Data Changes Without Prodly

Without automation, deploying a change to your product catalog or other configuration data in Salesforce CPQ can be a complicated, painstaking, and time-consuming process.

For every root object, you have to migrate all the related objects–so both the parent and child objects—to ensure the configuration changed works when it is deployed to production.

Let’s say you’ve made changes to your Product object, which has dozens of parent and child relationships.

When you have to move the newly-configured Product records from your Developer sandbox or scratch org to integration, you also have to move related records in all those parent and child objects. And because Salesforce record IDs change between environments, you’ll need to map IDs to maintain those relationships.

Manually.

For every single record. One object at a time.

Then you have to do it again when you move the changes to UAT. Manually. For every single record. One object at a time.

And again when you move them to staging.

And again when you promote them to production.

How long does this take? Hours, if not longer. Oh, and that’s assuming everything went according to plan and there weren’t any errors that required a do over.

The Market-Leading Salesforce CPQ DevOps Tool

See how easy it is to run a Salesforce CPQ deployment with Prodly DevOps compared to without?

Prodly is truly the best-in-class DevOps tool to enhance the benefits of Salesforce CPQ, and it offers even more brilliant features than described above! Our state-of-the-art platform includes work management integration, version control, effortless work deployment, and easy compliance. 

Getting up and running is a breeze—and super fast. Plus, if you have any questions at all, our support team is rated one of the best in the industry.

Discover how Prodly DevOps can streamline your Salesforce CPQ instance and accelerate your digital transformation!

Enjoy this blog? Sign up now—and be the first to know when we publish something new!

The importance of version control in Salesforce
Analyze, Best Practices, Salesforce DevOps, Version Control

Versioning and Backup in Salesforce

Leave a comment

Versioning tracks the flow of changes in your code, metadata, or configuration data. It’s important because it provides an auditable history of changes. You can refer to this history if you need to roll back to a previous version due to an issue. You can also refer to it for SOX compliance purposes. Versioning also facilitates collaboration.

Backup is the practice of routinely taking a snapshot of your Salesforce org. Its value is that you can use it to restore and recover your records in the event of a disaster.

In this blog, we’ll take a closer look at the definitions of versioning and backup. We’ll examine the importance of backup and source control in Salesforce DevOps. And we’ll describe how to use each of these methods to accelerate development in Salesforce with less risk.

The importance of version control in Salesforce

What Is Backup?

A backup is a copy of a portion or all your metadata, configuration data, and transactional data from your production org. You store this backup outside of your Salesforce production org. It allows you to recover and restore your production org to the most recent snapshot if you suffer data loss or corruption.

Data loss can occur due to a serious technical issue, an employee mistake, a bad actor, or even a cyberattack. As such, backup is a critical aspect of data management and data security.

Backing Up Data and Metadata

You need to have a defined backup strategy for both your data and metadata.

Back Up Your Data

To backup your data, you can use:

• Data Export App: Manual or scheduled exports of your data using the UI
• Data Loader: Manual, on-demand exports of your data using the API
• Report Export: Manual, on-demand exports of your data using reports

Many companies back up their data to external cloud storage outside of Salesforce, as well as to hard drives.

Back Up Your Metadata

To backup your metadata, you can use:

• Change sets: Copy metadata from production to a sandbox or Developer environment.
• Sandbox refresh: When you refresh a sandbox, the metadata is automatically copied over.
• Force.com Migration tool: Java/Ant-based command-line utility for moving metadata between a local directory and a salesforce org
• Package Manager: Create an unmanaged package of your metadata to save in Salesforce.

Salesforce Backup and Restore offers backup, recover, and restore for Salesforce. It lets you create backup policies that automatically generate backups. In addition, you can use it to restore data in just a few clicks.

There are also various third party backup solutions available on the AppExchange.

Why Should I Back Up My Salesforce Data?

It’s essential to routinely back up your Salesforce data as a part of your overall data management and security model. There are so many things that can cause data corruption or loss. Think of a bug, technical glitch, virus, or intentional data theft by a bad actor. Backup mitigates the risk.

If part or all of your org is wiped out, your users can’t do their jobs anymore. You lose the record of what you’ve sold and delivered, as well as what the next steps are with a customer. Worse: Your customers would be in for a terrible customer experience. This in turn has a whole host of consequences, including financial, reputational, and even legal repercussions.

When you have your data backed up, you can easily restore it and get back to business as usual. A backup won’t protect you from data corruption or data loss, but it makes it easier to recover from a catastrophic incident.

What Is Versioning?

Versioning is also referred to as version control or source control. It provides a single source of truth, as well as automation, that lets teams make changes to Salesforce faster and more reliably. It also improves collaboration across the team.

What Does Versioning Involve?

Versioning involves maintaining an accurate history of all changes made to how the production org is set up in a shared repository. It automates many of the tasks associated with maintaining an auditable history of the org’s changes.

With this detailed change history, you can easily pinpoint and undo any change when you need to roll back a change in Salesforce.

Backup reverts the entire org to the previous snapshot. In contrast, versioning offers the targeted rollback of specific changes made during development.

Source Control for Low-Code Apps

Pro-code developers have used version control systems (VCS) for decades. However, because Salesforce is a low-code application, source control has only recently become available to low-code admins.

Third-Party Tools for Versioning in Salesforce

There are several third-party tools that provide versioning for Salesforce, like Prodly DevOps. In addition, Salesforce DevOps Center integrates with GitHub, which provides a powerful source repository.

Versioning involves:

Maintaining a Shared Repository

The VCS has to maintain a shared repository for everyone on the team of all project code, metadata, and configuration data on a server. This shared repository must have a form of automatic backup.

Tracking Changes per File

The VCS must track changes per file (such as a metadata component or a Price Rule) that you commit to the repository. This allows you to review a file’s entire history. If you commit multiple files as a bundle, you can see the changes to them, as well. Additionally, it also makes it easier to determine failures from a specific change. Plus, you can easily revert one file or a bundle of files to the previous state… or any state before that.

Storing the Code or Data Somewhere Changes Can Be Detected

The code, metadata, or configuration data must be stored in a place where a build system like Salesforce or VS Code can detect changes to the repository. The build system then automatically triggers a build and an immediate integration test.   

Managing Conflicts and Overwrites     

The version control system must manage conflicts and overwrites among multiple users. The source control system can do this by leveraging tools that automatically merge changes and detect conflicts. It may also require individual developers to lock the files they’re working on so only they can access them.

Sending Automatic Notifications

The VCS must send automatic notifications to developers when specific files change or when they need to manually resolve merge conflicts.

Why Enable Versioning in a Salesforce Release Pipeline?

Managing Salesforce changes in a source repository is the foundation of automating your release pipeline. To enable true CI/CD, Salesforce or VS Code need to know instantaneously when you’re making changes to the repository. Versioning instantly updates the source code when you make a change. This offers five distinct benefits.

Change History

It maintains a change history, which allows you to restore components or parts of components to before the last change with laser precision.

Collaboration

Versioning facilitates collaboration, because multiple people can seamlessly work on the code, metadata, or configuration data at the same time. They won’t overwrite each other’s changes or introduce changes that could break any functionality.

Change History

It provides an accurate history of the who, what, when, and why of all changes that were made. This is critical in apps like Salesforce CPQ or B2B Commerce that require meticulous change tracking for SOX compliance purposes. The detailed history of changes makes the source repository auditable over time.

Because you add notes when you commit changes, you can link the why of a change to a specific user story.

Troubleshooting

Versioning enables troubleshooting as early as possible in the release pipeline, which helps minimize costs. Because versioning facilitates continuous integration, every change you make triggers an automatic build. It also runs automated tests. If the change causes any kind of conflict or issue, you’ll know about it in just a couple of minutes.

Should I Use Version Control or Backup in Low-Code Salesforce Apps?

Version control and backups are clearly not the same thing. Version control helps accelerate your development cycle, and backups protect you from the consequences of data loss or corruption.

In Salesforce, each method plays an important role:

• To safeguard your transactional Salesforce data such as Accounts, Contacts, and Opportunities, back up your data using either data exports or a data backup solution.
• To accelerate development and releases, use source control to manage and version code, metadata, and configuration data.

If you want to adhere to DevOps best practices, you can’t use a backup solution for source control in Salesforce. Why? It doesn’t provide the automation you need for continuous integration. On top of that, a backup solution also doesn’t provide the granular change tracking you need for versioning and compliance.

Continuous Source Control Software for Salesforce

A comprehensive DevOps solution like Prodly DevOps offers the ability to integrate your release pipeline with GitHub, Bitbucket, and Azure. This provides you with meticulous change tracking and version control for metadata and configuration data in Salesforce. It enables fast and easy rollbacks if needed. Plus, it ensures SOX compliance. It also facilitates streamlined collaboration between your team members.

To learn more about Prodly DevOps, request a personalized demo.

Enjoy this blog? Sign up now—and be the first to know when we publish something new!

The business case for automated sandbox seeding.
Business Benefits, Salesforce DevOps, sandbox seeding

The Business Case for Automated Sandbox Seeding

Leave a comment

Automated sandbox seeding can significantly accelerate digital transformation. It allows businesses to boost the pace of Salesforce innovation, save money on Full Copy sandboxes, improve governance and data security, and reduce attrition. Moreover, it empowers them to reduce the time to value of their Salesforce investment.

In this blog, we’ll take a closer look at the business benefits of automated data seeding.

The business case for automated sandbox seeding.

Accelerate the Pace of Salesforce Innovation Without Sacrificing Trust

Automated sandbox seeding results in a streamlined release pipeline, which enables faster innovation. Because it offers a less risk-prone alternative to making changes in the production environment, it drastically reduces the chances of errors, bugs, and downtime. This is critical to maintaining trust with business users. 

Save Money on Full Copy Sandboxes

With sandbox seeding, Salesforce teams can use Developer sandboxes or scratch orgs like Full Copies. Each Full Copy sandbox costs 30 percent of a business’s net spend in Salesforce. As such, organizations can save a significant amount of funds on change management.

Improve Governance and Data Security

Prodly Sandbox Management provides control over who can deploy what data to which environments. This improves governance. In addition, because sandbox management eliminates the need to download data to CSVs and enables the masking of sensitive data during deployment, it greatly enhances data security.

Reduce Attrition

According to a Salesforce survey, 89 percent of full-time workers are more satisfied thanks to automation. Moreover, an astounding 91 percent agree that automation saves them time and gives them a better work-life balance. When high-performing employees experience enhanced job satisfaction, it leads to improved retention. This greatly reduces the costs associated with acquiring and onboarding new talent and significantly contributes to an organization’s human capital.

Decrease Time to Value of Your Salesforce Investment

As a result of more efficient employees and faster, more streamlined release processes, Salesforce teams can increase productivity by 80 percent. As a result, they have more time to focus on value-adding work. Moreover, the business starts realizing the value of its Salesforce investment that much faster.

Prodly Sandbox Management

Prodly Sandbox Management is a powerful tool to manage all environments in the development landscape. Its one-click scratch org creation and sandbox seeding features drastically reduce the time Salesforce teams spend on setting up and syncing environments. Plus, its governance features ensure the business is always in compliance with regulations. 

As a result, Salesforce teams can work faster and compliantly, produce more and better work, and help propel the business forward.

For more information about Prodly Sandbox Management, please request a personalized demo. 

Streamline Salesforce CPQ deployment
Analyze, Data Deployment, Salesforce DevOps

Prodly Boosts Salesforce CPQ Data Deployment

Leave a comment

In this blog, we explain how Prodly accelerates your Salesforce CPQ data deployments.

Boost Salesforce CPQ Deployments

With Prodly, you can quickly and easily deploy Salesforce CPQ data to production.

Created by the team that developed Salesforce CPQ, Prodly is the # 1 data migration tool for Salesforce. It streamlines the process of deploying Salesforce CPQ configuration data for seamless release management. 

With Prodly, you can deploy changes 66 percent faster than other solutions. What’s more: You can ramp up productivity by an astounding 80 percent!

Prodly streamlines Salesforce CPQ deployments because it offers several distinct benefits for users.

Streamline Salesforce CPQ deployment

Its Algorithms Are Optimized for Salesforce CPQ Data Migration

We’ve been perfecting our data deployment algorithms since 2015. Although Prodly was originally developed as a tool to streamline Salesforce CPQ deployments, we’ve developed our tool so it can be used with any Salesforce application. It’s still our core focus and main product.

It’s also important to note that we’re the only company in this space that originally focused on data. Other companies began with metadata and have only recently started to build out their data capabilities. As such, Prodly’s data migration capabilities are much more advanced.

It Provides Full Support for Any User From Start to Finish

Prodly is extremely user-friendly. It’s easy to navigate for admins and revenue operations, yet robust enough for developers. It’s a “clicks, not code” tool with a powerful DX plugin that allows you to move all data within Salesforce, without limits. 

Prodly offers fully automated data deployments, even for highly complex, Salesforce CPQ object models. It automatically determines the correct sequence for multi-object data loads. You don’t need any knowledge of CPQ schema, so everyone on your team can use the tool.

It Knows Which Records to Insert and Which to Upsert

Prodly makes sure your data upserts correctly. Automatic record matching understands the relationships between your records and maintains them in the destination org. This prevents duplicates. 

Recursive processing takes multiple passes through the data to make sure it updates with the correct information. Sometimes this requires the addition of a temporary value so the record can upsert. Later, Prodly goes back and updates the record to the real value.

For example, Price Rules of the type “Custom” require child conditions. So Prodly is smart enough to create Price Rule records in the default type and insert child condition records. Then it goes back and updates the Price Rule records to Custom.

With Lookup relationships and hardcoded IDs, Salesforce stores a record ID. This record ID changes in the destination org, which breaks the relationship between records. Prodly determines which record matches in the destination org and simply updates the IDs accordingly.

It Offers Superior Functionality for Every User Without Compromising Ease of Use

Prodly is completely reliable for Salesforce CPQ deployments. The Diagram View allows non-technical users to easily see what’s being moved. You control all settings down to the field level with a single click. 

It provides pre-built templates that empower you as your needs mature. You can even customize the templates so they’re specifically geared towards your needs.

It Offers Peace of Mind During Development From Start to Finish

Prodly lets you securely move any data to any org within Salesforce. It provides one-click data masking, as well as automatic duplicate, override, and error prevention. 

Prodly also offers easy Git integration for source control because it’s critical for commerce businesses to be SOX compliant,  This helps you enhance your governance and release process with version control.

When to Choose Prodly for Salesforce CPQ Deployments

Prodly is best used when you need to migrate large volumes of highly complex relational data. This occurs frequently in Salesforce CPQ. Just consider how often you need to make changes to reflect factors like seasonal promotions, sales in new territories, etc. And then consider across how many different products or artifacts you need to make those changes.

Clearly, you need a powerful Salesforce CPQ deployment tool that lets you focus on making the changes to the data. 

To see Prodly in action, request a personalized demo. 

An abstract image showing a concept of Salesforce DevOps
Salesforce DevOps

Salesforce DevOps: What Took So Long?

Leave a comment

Salesforce DevOps has been a long time coming. However, DevOps has long been a popular methodology for IT teams. So what has caused the slow adoption of DevOps by the Salesforce community?

First, Salesforce isn’t a code-first environment. Second, the production org has always been the source of truth. And third, creating reproducible environments has been extremely challenging. 

In this blog, we take a closer look at these factors. Then we explain how Prodly directly addresses each one to facilitate Salesforce DevOps. 

An abstract image showing a concept of Salesforce DevOps

3 Reasons Salesforce Was Slow to Adopt DevOps

We can attribute the Salesforce ecosystem’s slow adoption of DevOps to the following key principles.

1. Salesforce Is Not a Code-First Environment

Salesforce is first and foremost a low-code platform. It’s as much declaratively configured as it’s programmatically configured. That’s why it’s such a great tool for low-code developers such as Salesforce admins and citizen developers.

Often, Salesforce admins, business analysts, and project managers have great ideas. Unfortunately, they’re still excluded from conversations due to their inability to work with code-heavy DevOps tools.

To achieve successful adoption of DevOps for any team, low-code and no-code citizen developers must be first-class citizens from the very beginning. This is why Prodly DevOps is designed with the lowest technical user in mind. 

2. The Production Org Has Historically Been the Source of Truth

Within Salesforce, we think of production as the source of truth. The problem is that production is always evolving—and there’s no real history of changes. 

In DevOps, the code is the source of truth. The code is versioned, and every change is stored in a repository so it’s easy to roll back changes if there’s an error. Think of the “track changes” feature in a document.

For Salesforce DevOps to be successful, we need to version not just the code, but also the declarative configurations. 

This is why Prodly helps you version your Salesforce data with GitHub, Azure, and Bitbucket integrations.

3. Creating Reproducible Environments Has Been Challenging 

One important DevOps principle is to be able to easily create reproducible environments. 

Why? Because by giving each developer their own org, they have a safe place to play around and test new ideas without stepping on each other’s toes. So it’s imperative to be able to quickly spin up and discard new orgs.

Salesforce has sandboxes. However, they’re not truly reproductions of production because they don’t contain all your data. 

Even Full Copies get out of sync with production quickly—plus, they can only be refreshed every 30 days. 

Salesforce data is highly relational, and those data relationships are hard to maintain org to org. That’s why most companies fall into one of two buckets:

  • Everyone shares the Full or Partial Copy sandbox. All the work happens here, and people overwrite each other’s work by mistake. This frequently results in access restriction to certain data. 
  • They work in Developer Pro sandboxes without the right test data, meaning they can’t efficiently build new stuff or test it very well.

To be successful with Salesforce DevOps, you need to be able to create true copies of production. What’s more: You need to be able to do this really quickly.

That’s why Prodly Sandbox Management allows you to select, filter, and seed data into any org in minutes. Check out Maximize Your Salesforce Orgs With Sandbox Management to learn more.

Schedule a demo to discover how to enable Salesforce DevOps with Prodly.