Tag Archives: configuration data

An vector diagram depicting running a Salesforce CPQ deployment

How to Easily Run a Salesforce CPQ Deployment

Learn how to easily run a Salesforce CPQ deployment using Prodly’s automation templates. It takes 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!

A photo that complements the benefits of implementing salesforce cpq

The Benefits of Implementing Salesforce CPQ

In this blog, we explain that implementing Salesforce CPQ is more efficient than a manual CPQ system because it costs less time, minimizes manual work, and eliminates errors.

It streamlines the sales process, improves the customer experience, gives your sales team more time, and, as a result, increases revenue. In addition, it offers a more scalable solution that can grow along with your business.

A photo that complements the benefits of implementing salesforce cpq

Advantages to Implementing Salesforce CPQ

Implementing Salesforce CPQ, an automated system for generating quotes in Salesforce, offers many benefits when compared to using spreadsheets or a homegrown system.

Enhanced Efficiency

The manual use of spreadsheets or a system that’s cobbled together from multiple different processes for CPQ is highly inefficient. Why? Because it’s labor intensive, time consuming, and prone to error.

In contrast, Salesforce CPQ automates the configure, price, quote process in one powerful app.

It automatically narrows down product selections for customers to those that are most relevant based on factors such as need and company size. It helps sales reps with any additional configurations. Plus, it can even suggest fitting add-ons like extended service contracts, extra training sessions, or complementary products.

Because you’ve entered your standard pricing into Salesforce CPQ, the app provides guidance for sales reps to add package or line-item discounts. It can even be configured so you can enter a client’s budget and the software automatically generates matching product discounts. As a result, you can create quotes that capture better value.

Salesforce CPQ also generates a customer-ready quote that can include your branding, cover letters, specific T&Cs, and marketing materials.

More Streamlined Sales Process

According to Salesforce, using CPQ software results in:

  • 10 times faster quote generation thanks to automation
  • 95 percent reduction in approval time due to automatically enforced business rules for pricing and configuration
  • 2 times faster moving from quote to cash because sales reps can move faster
  • 30 percent quicker ramp up for new reps thanks to the use of a single automated process

Clearly, the sales process is significantly streamlined compared to using a manual method.

Improved Customer Experience

The customer experience is significantly improved. Why? It’s significantly faster to generate an accurate quote with any additional offers or product suggestions that apply.

So there’s less time between the customer’s exploration of the product and their receiving of an indication of the cost. This shortened time period keeps the momentum going.

At the same time, the customer receives a correct, automatically-generated, branded quotes that contain all the terms and conditions. It’s not a document with text that’s cut and pasted from a bunch of other sources. Instead, it’s a standardized contractual document that has been reviewed and approved before it goes to the customer.

More Time for Your Sales Team

With the automation offered by Salesforce CPQ, your sales reps spend less time on creating accurate, professional quotes and proposals. This means they have much more time to prospect, generate leads, and close more deals.

Scalability and Flexibility

To ensure smooth business growth, you need a CPQ solution that scales along with your CRM—like Salesforce CPQ. Because Salesforce CPQ is a Salesforce-native app, you don’t have to worry about upgrading the integration with your CRM.

Moreover, Salesforce CPQ is highly flexible and lets you easily customize it to add new features and products when needed.

Increased Revenue

We discussed how Salesforce CPQ gives your sales reps more time to prospect and generate leads, as well as a significantly shorter sales cycle. As a result, your business can see a significant increase in revenue. 

Plus, because Salesforce CPQ is cloud based, it’s accessible from anywhere. This provides sales reps with more freedom to generate quotes and close deals on the move.

In addition, by spending less time on the CPQ process thanks to automation, you can reduce your operational costs.

Enhance Your ROI With a Salesforce CPQ DevOps Tool

You can increase your revenue even more by automating the change management process in Salesforce CPQ with Prodly DevOps. Prodly’s state-of-the-art automation minimizes the manual work associated with data and configuration data migration and integrates seamlessly with DevOps Center. 

Using our Salesforce CPQ DevOps tool, you can deploy work 80 percent faster, reduce operational costs, and increase productivity.

Moreover, Prodly offers 1-click scratch org creation and sandbox seeding, built-in work management, and sandbox management. It provides automatic audit trail creation, as well as version control integration with GitHub, GitLab, Azure, and soon Jira. All this together make it the most effective end-to-end DevOps platform for Salesforce—all managed through a single pane of glass.

Discover Prodly DevOps for yourself—request a demo!

The problem with Salesforce CPQ configuration data deployment

The Problem With CPQ Configuration Data

In this blog, we’ll examine the issue with deploying Salesforce configuration data and discuss why deploying metadata is easier. We’ll explain why Salesforce managed packages use configuration data in the first place—plus, we’ll mention how to streamline Salesforce CPQ configuration data deployment.

The problem with Salesforce CPQ configuration data deployment

The Issue With Deploying Configuration Data in Salesforce

Configuration data, or reference data, achieves a specific functionality in a Salesforce app. It’s like metadata in that it describes how the system behaves. However, it’s stored as transactional data in Salesforce’s databases. 

Because Salesforce doesn’t have tools to manage reference data, it’s critical for Salesforce CPQ users to understand why it exists and how it works.

It becomes particularly challenging when you need to promote many changes with complex relational data from a sandbox to production. You can’t use change sets, because they only work for actual metadata types.

You can use Data Loader–but that can be a laborious, lengthy, and painstaking process. Especially when you have a high volume of complex relational data, like in Salesforce CPQ, you can spend hours mapping objects. And that’s before mistakes and do-overs.

Why Is Migrating Metadata Easier?

In Salesforce, metadata is native to the platform. Salesforce can create new types of metadata when needed and has hundreds of types of metadata to power its applications.

For example, Salesforce created Einstein bots—with dialog as a new custom metadata type within the platform. 

Once the dialog was added as a metadata type, customers could develop their own bots in a sandbox. Then they could define the bots’ interactions with end-users based on the dialog metadata provided. 

Now, when they wanted to deploy those bots from a sandbox to production, they could simply use change sets. Why? Because the metadata types are already included in org migration tools that the platform provides. 

Why Does Salesforce CPQ Use Configuration Data?

If deploying metadata is relatively easy, why do some Salesforce apps use configuration data?

The answer is simple. Many apps are made by Salesforce App Partners (otherwise known as ISVs) who don’t have the ability to create new types of metadata. So when they want to specify behaviors in their applications, they need a solution. That’s where configuration data comes in.

Configuration data are records that serve as the code used by managed packages to produce some type of application behavior for applications built on Salesforce. 

For example, Salesforce CPQ is an AppExchange product originally created by Salesforce App Partner, Steelbrick. Even after Salesforce acquired Steelbrick, you still need to install the CPQ managed packages in your org to gain access to its many powerful features and functionalities.

One of these functionalities is Price Rules—conditions and actions that update prices. However, when Steelbrick developed Price Rules, it wasn’t an option to create a new type of metadata like with our Einstein dialog example. So they needed a different solution. 

Instead, they developed Price Rules as a custom Object made with configuration data. 

However, when you, the user, make changes to Price Rules, you can’t use change sets to promote those changes to production. Because they’re configuration data, you need to promote them as data.

Read Prodly Accelerates Salesforce CPQ Data Deployment to discover how to do this quickly and easily. 

Version control in Salesforce

What Is Version Control and What Are Its Benefits?

A version control system (VCS) tracks and manages the changes you make to your data and configuration data. It’s critical to managing changes in low-code Salesforce apps that use complex configuration data, like Salesforce CPQ and Field Service Lightning. 

A VCS offers many benefits, including faster iterations and configurations, improved collaboration within teams, and enhanced compliance. 

Version control in Salesforce

What Is Version Control?

Ever wish you could roll back changes you just made to your production org in error? How about being able to track the revision history of your changes over time?

Version control (also known as revision control or source control) is a methodology that resolves data control and management scenarios like these.

A VCS tracks and manages the changes you make to your data. In Salesforce apps that use configuration data, tracking changes as you move the data from Developer sandbox to QA to UAT to production is paramount. 

Especially in DevOps, where your changes occur fluidly, dynamically, and rapidly, version control is an essential component of configuration data management. That’s why it’s increasingly becoming a necessary element of the release management process.

The Benefits of Prodly With Version Control

Prodly with version control makes agile development a reality for complex, low-code Salesforce apps. Unlike other version control offerings for Salesforce, Prodly manages your configuration data, which makes it perfect for Salesforce CPQ, FSL, Billing, and B2B Commerce.

Prodly version control combines the power of Salesforce orgs and VCS branches. Using Prodly version control as your single source of truth has the following benefits when compared to traditional in-org development:

  1. You can iterate and configure faster in a truly agile environment.
  2. It improves collaboration within and amongst teams.
  3. You can ship complex configuration features faster.
  4. You can identify conflicts head on.
  5. It provides a full change history and audit trail.
  6. It allows you to maintain SOX compliance.
  7. You can easily roll data back to prior states.

How Does Version Control Work in Salesforce?

Version control in Salesforce works like this:

The initial master data commit retrieves your configuration data from your Salesforce production org and stores it in the VCS. At that point, the data in the VCS becomes your single source of truth. Going forward, you initiate all changes to data in your production org through the VCS.

A version in the VCS is a snapshot of your data at a given time. You check data out of the VCS, update it, and check it back in, creating a new version against which further changes are made. Then, if needed in the future, you can roll back your data to any version.

The VCS records all the changes you make so you can easily roll back to an earlier version if necessary due to a bug. At the same time, this change tracking creates an audit trail you can use for compliance purposes.

Does the VCS Replace My Deployment System?

You might be wondering whether the VCS replaces your deployment system. The short answer is no, it does not. 

The VCS works in conjunction with your deployment system through a concept called branching. A branch is a snapshot of your data created in the VCS and then deployed to a separate Salesforce sandbox or development org. 

Similar to how you likely work now, you develop your new features in the separate org to protect the data in your production org. When you’re ready, you check the changes back into the VCS branch, merge the branch back into the master, and deploy the changes to your production org.

To learn more about Prodly, request a demo.

Salesforce B2B Commerce Cloud

Salesforce B2B Commerce Cloud Implementation Made Easy

Prodly and Docmation have developed a new Prodly Toolkit for Salesforce B2B Commerce Cloud. The toolkit is purpose built to help admins follow DevOps best practices by making deployments and migrations efficient and secure. 

 

Salesforce B2B Commerce Cloud

Challenges With Salesforce B2B Commerce Cloud

Organizations are increasingly looking to engage more customers, scale their businesses, and tailor their products and services to a demanding clientele. B2B buyers’ expectations are more closely mirroring those of consumers. To meet these demands, many businesses are investing in Salesforce’s B2B Commerce.

Salesforce B2B Commerce Cloud  is a powerful, highly-customizable, and complex platform. However, without DevOps tools to insure success, businesses may not realize the return they expect from their investment. 

DevOps for Salesforce B2B Commerce

Prodly and Docmation understand these client needs and partnered to develop a new Prodly Release Toolkit for Salesforce B2B Commerce. 

Users must properly map and update configuration data to reduce the risk of errors and increase solution’s effectiveness. With the Prodly Release Toolkit, Salesforce admins can easily follow DevOps best practices to efficiently and securely deploy and migrate data.

The Toolkit Developers

Junaid Mohammed worked with Dave “Stuff” Stufflebeam to develop the toolkit. 

Junaid is Docmation’s Lead Salesforce Architect and has over 14 years of programming and Salesforce expertise. In addition to his certifications, he has configured and implemented Salesforce B2B Commerce for multiple clients. 

Stuff, Prodly’s Product Manager for Solutions, is a configuration data deployment expert and trainer. He co-developed the Prodly toolkits for Salesforce CPQ, Billing, and Field Service Lightning applications. He’s also trained hundreds of Salesforce architects, admins, and consultants on managing and deploying reference data in those applications.

The Prodly Release Toolkit for Salesforce B2B Commerce

The Prodly Release Toolkit for Salesforce B2B Commerce includes resources to help companies implement, launch, and manage the application. 

Prodly customers save days of manual, error-prone processes when deploying configuration changes for Salesforce CPQ, Billing, FSL and custom apps. B2B Commerce presents the same complexity of configuration data and inefficiencies when it comes to updating it. That’s why Prodly and Docmation are excited to bring the same benefits to B2B Commerce customers.

“We’re thrilled to help B2B Commerce customers drive agility in their businesses and improve ROI. Our toolkit does this by reducing the burden of maintenance and enabling more frequent updates. Prodly’s grateful to Docmation for their partnership and invaluable expertise in the B2B Commerce application.”

Want to learn more about Prodly’s Salesforce B2B Commerce Toolkit?  Check out reviews on the Salesforce AppExchange and G2, or request a demo.

Interested in learning more about Docmation and Salesforce B2B Commerce? Visit Docmation’s page or docmation.com.

About Docmation

Docmation is a Salesforce Silver Consulting Partner, particularly focused on implementing robust Salesforce communities and B2B E-Commerce. Over 10+ years, the Docmation team has serviced more than 200 clients. Their focus is on quality, communication, customer satisfaction, and tech-savvy culture. The Docmation team comprises more than 60 certified Salesforce experts.

About Prodly

Prodly is a Salesforce ISV Partner dedicated to making Salesforce administrators and developers more productive. Our flagship product, Prodly, enables one-click deployment of configuration data between Salesforce orgs. Over 120 companies across the globe leverage Prodly to embrace business agility and efficiently manage their Salesforce low-code applications.

Salesforce Billing

Accelerate ROI on Salesforce Billing

Prodly and ATG, a Cognizant Company, have launched a new Prodly data set template for Salesforce Billing. Prodly’s lightning fast deployment capabilities and duplicate record prevention measures will help Salesforce admins prevent errors when billing customers. As a result, the template will help businesses accelerate their ROI on Salesforce Billing. 

Salesforce Billing 

Why You Need Prodly’s Data Set Template for Salesforce Billing

Accidental errors when billing a customer are embarrassing and can affect your company’s image, potentially resulting in lost business. 

Although Salesforce Billing is a powerful tool to streamline your billing process, you need to regularly update reference data, also referred to as configuration data, within this application to reduce the risk of billing errors. If the reference data is out of date, your sales and billing teams are forced to make manual changes. If they’re even aware of the error, that is.

Prodly provides an easy-to-use tool for admins to update their configuration data within Salesforce CPQ. This minimizes errors and potential losses. 

Billing Configuration Data Dream Team

Sonia Flamm, ATG’s Salesforce Billing Practice Lead, and Dave “Stuff” Stufflebeam, Prodly’s Sr. Solutions Engineer, collaborated to develop the template. It’s designed to help companies using Billing to succeed with the app self-sufficiently. 

Sonia is known throughout the Salesforce community as a Billing evangelist and guru. She has traveled the world to train hundreds of Salesforce consultants and admins in implementing and maintaining  Billing. 

Stuff, who leads Solution Engineering at Prodly, is a reference data deployment expert and trainer. He has trained hundreds of Salesforce architects, admins, and consultants in deploying Salesforce CPQ reference data. He’s responsible for creating Prodly’s data set templates for Salesforce CPQ, Billing, Advanced Approvals, and Field Service Lightning (FSL).

Salesforce Reference Data: Use Clicks, Not Code

Reference data defines the set of permissible values other data fields may use. Within Salesforce applications, reference data is how admins are able to use clicks instead of code to configure their Salesforce environments. 

If you’re a Salesforce CPQ or Billing administrator, and configure apps like Price Rules and Product Rules, this becomes record data, not metadata. That means you can’t deploy it using a change set. Prodly and the Prodly template for Salesforce Billing are purpose built to deploy reference data from your Billing developer org to QA, UAT, and eventually into production.

Implementation and Ongoing Deployment

During the initial configuration of Salesforce Billing, many companies utilize an implementation partner, like ATG, to ensure the application is properly set up. Regarding implementing Billing, Sonia Flamm remarked, “Billing isn’t simple. It has a lot more relationships between all these objects. There are a lot more interdependencies.” 

There’s tremendous value in a well-implemented and perfectly configured instance of Salesforce Billing. However, it takes time, work, and expertise to get to that point—and can take even more time, work, and expertise to maintain it.

It’s best to perform both the initial configuration and ongoing deployments of Billing reference data using a series of sandboxes. Once the application works in the sandboxes, you can deploy it to production. Here, it will go live so employees can use it to automate billing processes.

You have to regularly review and update reference data. For example, billing schedules may change from monthly to quarterly, and any changes to tax law will need to be reflected in the reference data for accurate billing. Not every object in Billing contains reference data. Some objects, like quote, refund, and payment authorization contain transaction data. Yet others are for internal use only.

Salesforce Billing Objects That Contain Reference Data

In total, there are 70 objects in Salesforce Billing, and 22 of them contain reference data. This configuration data defines the permissible values for each of the objects, ensuring that all bills generated with Billing are accurate to your business.

You can find a full list of Billing objects and their data types in the Prodly Salesforce Billing Reference Data Deployment Guide.

Easily Manage Configuration Data Deployment in Salesforce Billing

It’s challenging to keep up with reference data updates using a data loader and spreadsheets. You have to remap the lookup IDs between related records before moving them from the source org to the destination environment. This process is slow and prone to error. 

On top of that, it can take hours of additional work to prevent duplicates by mapping formal external IDs before updating the reference data in a given org. Not to mention weeding out duplicates that have slipped through the cracks once the update is complete. 

Prodly was purpose built to eliminate the challenges associated with reference data deployment. It offers three external ID upsert methods to simplify this error-prone aspect of the deployment process.

“It’s almost ten times more important in the Billing platform to deploy reference data correctly in the right order. Otherwise, you’re going to mess up your billing information, which is a really big deal,” said Flamm. “Prodly helps somebody who may not be an expert in Billing.”

Prodly’s template for Salesforce Billing makes our productivity-enhancing reference data deployment tool even easier to use with  Billing. The template contains prebuilt data set templates that simplify the deployment process, as well as our complete deployment guide and expert support.

To learn more, request a demo.

Field service lightning - field service worker with tablet

Reference Data in Field Service Lightning

Reference data makes the implementation of Field Service Lightning (FSL) complex. That’s why Prodly released the Prodly Toolkit for Field Service Lightning to offer admins a streamlined, hassle-free data deployment environment. 

Easily Deploy Configuration Data

With the release of the Prodly Toolkit for Field Service Lighting, we’re offering FSL admins the same hassle-free deployment that we’ve provided to admins of Salesforce CPQ. 

Salesforce CPQ’s product catalog, price rules, and discount rules are easily recognizable as objects containing reference data, also referred to as configuration data. However, with Field Service Lightning, it’s no always so clear cut. What objects require updates via reference data deployment, and how do you make it happen?

What Is Salesforce Reference Data?

Reference data defines the set of permissible values to be used by other data fields. It’s used amongst other things in Salesforce applications like Salesforce CPQ, Billing, Advanced Approvals, and Field Service Lightning. In these applications, configuration data allows users to configure their Salesforce environment to their business’s needs without having to code.

The ability to extend the usefulness of Salesforce to meet the unique challenges of your business through clicks, not code, is an extremely valuable selling point. A Salesforce admin may have little or no experience with developing on the Salesforce platform. However, they can still be able to keep the business’s marketing, sales, and customer success initiatives on Salesforce up-to-date and running smoothly.

So what does that mean for Field Service Lightning?

Field service lightning - field service worker with tablet

FSL Implementation and Ongoing Data Deployment

The initial implementation of Field Service Lightning is a complicated process. Many businesses use an implementation partner to ensure the application is set up properly.

First, the implementation partner collects data from existing systems; then they deploy it to a Salesforce sandbox org for testing. Once they’ve confirmed the app is working, it’s deployed to production. Finally, employees can use it to deliver a fast and intuitive service experience to customers.

You need to review and update reference data fairly regularly to maintain a useful data set. Operating hours may change seasonally, for example, or services may be added, changed, or removed. 

However, not all objects within Field Service Lighting contain configuration data. Objects that contain transaction data like service reports and work orders go through a different process during the everyday use of Field Service Lightning.

What Objects Typically Need Updating?

Of the 54 objects used in Field Service Lightning, 27 contain configuration data. The following 20 are most typically updated during a reference data deployment:

  • Operating Hours
  • Time Slot
  • Service Territory
  • Skill
  • Location
  • Address
  • Service Resource
  • Service Territory Location
  • Service Resource Capacity
  • Service Resource Skill
  • Resource Absence
  • Resource Preference
  • Work Type
  • Skill Requirement
  • Service Territory Member
  • User Territory
  • Scheduling Policy
  • Map Polygon
  • Service Crew
  • Service Crew Member

You can see a full list of Field Service Lightning objects and data types in our Prodly Field Service Lightning Reference Data Deployment Guide.

How Do You Manage Reference Data Deployment?

The Salesforce method of clicks, not code allows people without developer experience to manage and update Field Service Lightning. However, the traditional method of using a data loader and spreadsheets is by no means easy.

With a data loader, admins are required to manually remap the lookup relationships between the records and destination org. This is a tedious process that’s prone to errors. 

Moving data between a developer org or QA to production involves repeating this process several times. Failing to test changes can mean a breakdown in production, which can mean angry customers, disconnects, and lost business.

Our new Prodly Toolkit for Field Service Lightning makes Prodly, our productivity-enhancing reference data deployment tool, even easier to use for FSL. With data set templates to simplify the deployment process, our complete deployment guide, and expert support, we’ve made Field Service Lightning as easy to use for admins as it is for customers.