VP of Marketing
Hayley Coxon is the Vice President of Marketing and Revenue Operations for Prodly and accidental admin since 2010. You can find her on LinkedIn.
Coastal Cloud leverages Prodly to facilitate faster, more accurate Salesforce CPQ implementations.
Coastal Cloud is a Salesforce™ Platinum Partner based in Florida, with additional development centers in Kentucky and Colorado. They help clients leverage Salesforce Revenue Cloud (Salesforce CPQ and Billing) to improve business results and deliver a superior customer experience.
Q2C implementations can be a time-consuming process due to the complexities of relational data migration. Coastal Cloud has overcome this challenge by employing Prodly.
This Q&A with Mike Ackerman of Coastal Cloud discusses how his team uses Prodly to enable efficient Salesforce CPQ implementations.
I’m a senior technical architect at Coastal Cloud. I help our client implementation teams during the design, build, and deployment phases. I promote best practices and best-in-class tools so our consulting teams can deliver projects consistently and efficiently.
We’re a leading implementation partner of Salesforce Revenue Cloud, which includes Salesforce CPQ and Salesforce Billing. We’ve implemented some of the largest and most complex quote-to-cash deployments to date.
Coastal Cloud is on a shortlist of partners with deep experience in both CPQ and Billing. We’re a long-standing partner. We worked with SteelBrick, which was founded by Prodly’s CEO, before it was acquired by Salesforce and became Salesforce CPQ. We’re happy to say that relationship continues today.
We’ve performed many Salesforce CPQ and Billing deployments with complex configurations of products, pricing, availability, discounting, billing, and revenue recognition rules.
Our quote-to-cash projects range in complexity. We’ve completed simple Salesforce CPQ implementations for midsize companies and highly complex implementations for large enterprises. With quote-to-cash playing a central business role, we often integrate with ERP and other systems.
The real power of Salesforce CPQ is the flexibility and configurability. You need the ability to make product catalog reference data changes quickly and easily to leverage that power.
However, there’s a complex reference model working behind the scenes to enable this configurability in Salesforce CPQ. Implementation teams need to treat this reference data as another important artifact to be appropriately managed across environments.
When it comes to disciplined configuration management, you need to treat reference data as a first-class citizen. This is alongside the programmatic and declarative deliverables necessary to build and deliver the project.
Before we discovered Prodly, our teams executed a very labor-intensive process. It involved exporting configuration data changes to spreadsheets and meticulously loading them back into the target environments.
Salesforce’s internal IDs and lookup relationships are very complicated. So that load process had to account for the re-keying of relationship data. We needed to carefully load the parent and child rows in the correct order. Then we have to re-key the child rows to point to the newly imported parent.
This is a concern with related objects, as well as with rows within the same object that have a recursive relationship. You need to ensure that you’re loading the rows within the same object in the right order. Plus, you need to re-key those child rows before you can load them.
When you deliver changes to an existing target of reference objects, you identify each row with a unique external key. That way, you know if a row is being updated, inserted or deleted.
As you can imagine, using export spreadsheets with Data Loader can be a very labor-intensive and error-prone process.
After we discovered Prodly, this became a much more automated process. It saves us significant effort and reduces the risk of error.
Many factors impact the complexity of the Salesforce CPQ and Salesforce Billing model. Think of how many products are in the catalog, as well as the number of options and features you have. In addition, consider the complexity of the pricing and discounting rules.
All these factors influence the migration effort. However, it can easily take a full day to do one load without effective tools. This isn’t a scalable process when you’re following an agile development model.
In an agile development environment with two-week sprints, you want to set up and shut down feature development environments frequently.
To make your developers productive, provide them a full copy of the product catalog from which to develop and test. And you need to reduce that full-day migration process to execute refreshes reliably and frequently.
Let’s say we have three developers working on a two-week sprint. We start the sprint by setting up three empty DevPro orgs . Then we use Prodly to instantly populate these empty orgs with current product catalog reference data. Later, we’ll migrate that reference data to a fourth environment to support testing activities.
We also use Prodly for quick, ongoing deliveries of incremental data changes for bug fixes. When a fix is ready for production, we save time and reduce risk by delivering the final reference data using Prodly.
Note that we reduce our users’ outage window significantly by using Prodly during the production migration.
You’ve got to ensure you have a unique surrogate identifying key on each of the rows of the product reference objects.
Prodly uses this key to identify whether it’s an insert, update, or delete action when copying the data. Hopefully, a surrogate key exists in your data set already, but a lot of times we find one does not.
For instance, you might assume the product SKU is surrogate, but in reality there may be business meaning in that SKU. Perhaps those first two letters of the SKU indicate the line of business.
Perhaps the business team decides somewhere down the line that they want to change that SKU during a rebranding effort. Where you thought something was a surrogate unique identifier, it may in fact change in the future. That could break your deployment process.
Ideally, you want to start the project by identifying truly unique surrogate IDs for each row. You want the developers to set a surrogate ID once—and know it is never going to change.
IDs should have no business meaning and must reliably identify the uniqueness of a row as it moves across environments.
As Salesforce developers know, we can’t use the Salesforce ID for a surrogate key. The ID is not updatable and it changes as it moves from org to org. Surrogate IDs are an important success factor in making the reference data management process reliable.
Today, this is part of the startup steps for getting a Salesforce CPQ implementation project up and running. We install Prodly in the client’s org. Then we the data set or template for the objects we’re going to ask Prodly to move back and forth.
The data set represents the configuration, or instructions, on how the data will be moved. We define this initially in production to prepare for the copy of data from production to our development and test orgs.
When you’ve made changes in the development org, it becomes the new source. Those changes can be copied to test and later to production. To re-use the data set configuration we already defined in production, we copy it to the development org. That way, it can also facilitate that org’s new role as being the source for changes.
Currently, Prodly must be installed in any org that acts as a source for copying data. We can also use Prodly to push its own data set configurations to and from various source orgs. That way, we don’t need to re-define the data set from scratch. We’re essentially creating our own template.
With Prodly’s centralized deployment architecture, pushing data sets and installing Prodly in the various source orgs will no longer be necessary. Instead, we’ll be able to manage deployments from a central org. This will be another big time saver.
The centralized deployment console can potentially offer smaller clients a shared reference data management service based on Prodly.
Our standard methods and tools now include the use of Prodly for managing complex reference data migrations.
During our discovery phase, we identify if these challenges are present. Our teams identify this risk early and ensure the project is scoped to include the appropriate tools to mitigate this risk. This helps to ensure our clients and delivery teams are set up for success.
Prodly is a key part of our risk mitigation tool set.
Ideally, we want our clients to procure their own Prodly licenses. That way, once we’ve successfully delivered our project, the client’s Salesforce support team can continue to smoothly execute the process.
We ensure the process is well documented and train the client’s administrators on how to use the tools. We have a very robust configuration and release management process that’s well documented and repeatable.
Some clients opt to engage us for long-term Salesforce support. In those cases, which we continue to leverage Prodly for highly efficient reference data management.
Using Prodly, we’ve been able to dramatically improve the efficiency and quality of managing our Salesforce quote-to-cash data. We’ve taken a day-long reference data process and now execute it reliably in mere minutes. Prodly has drastically improved the way we operate and increased the ROI for our Salesforce quote-to-cash clients.
Do these Salesforce CPQ data migration challenges sound familiar to you?
Schedule a free demo now to see how Prodly can help !
The gold standard for documenting SOX in Salesforce CPQ!
