In the previous chapters, we learned about Salesforce's Configure, Price, Quote (CPQ) out-of-the-box configurations and used them to optimize the quote-to-cash process. Typically, many businesses won't have an existing CPQ implementation.
Often, a business uses spreadsheets, ad hoc software, in-house tools, or Salesforce standard objects to store data. When you decide to migrate such businesses to CPQ, you need to have a strategy for migrating data from those legacy sources into Salesforce, as well as being ready to anticipate a business process transformation. In this chapter, we will learn about successfully implementing CPQ and data migration.
Implementing CPQ is like building a home. You first need to lay the foundation for it. Understanding the data model is like building this foundation. Then, you can build relationships using CPQ with the products, bundles, options, features, price rules, product rules, approvals, quote templates, and so on that we have learned about so far in the previous chapters. For your convenience, you can configure some of the aforementioned stages in parallel too, but you need to be aware of the interdependencies in the implementation. In this chapter, you will learn about the CPQ data model and the interdependencies.
Finally, we will understand how the deployment of CPQ changes, from Sandbox to Production, play a crucial role in the implementation. All the changes need to be developed in a sandbox, following a project methodology that works for your company before migrating them to production.
Specifically, we will be covering the following topics:
In the previous chapters, we saw that Salesforce CPQ can dramatically improve the quote-to-cash process. Proper implementation is the key to success. Unlike Sales Cloud or Service Cloud, CPQ, across the platform, impacts several business stakeholders. As CPQ involves changing product configurations, pricing, contracting, order management, and much more, it involves different groups from your organization, such as product engineering, finance, sales, sales operations, and legal. Communication is important for a successful project implementation. In addition, not engaging the right people in a project is one of the biggest failures. Identifying key internal resources and building an implementation team consisting of management, business Subject Matter Experts (SMEs), and technical SMEs becomes crucial for successful implementations.
CPQ is a managed package; once installed, it's going to be embedded into the standard Salesforce package. You can use a standard data model, such as accounts, opportunities, products, and price books. You can use the standard Salesforce data from these objects to configure products, pricing, and other automation. You need to evaluate the state of this data to see whether the current data can be effectively used.
CPQ implementation is a major change in the way reps sell products and deliver quotes to customers. It is more than a system deployment; it's an organizational change. The following are some of the key points to be considered during CPQ implementation:
In any implementation, development can happen in multiple sandboxes. These can be either dev or dev pro environments. All the changes from a development environment need to be migrated to an integrated QA environment. Once the changes are tested, these changes need to be deployed into a full sandbox so that User Acceptance Testing (UAT) can be performed in this instance.
A UAT instance can be thoroughly tested end to end to complete testing of new and regression cases. CPQ testing and UAT should be conducted in a fully integrated environment. Once a business sign-off is complete, the changes can be deployed to a pre-production or staging environment. Then, finally, the changes can be deployed to the production environment. The following figure shows a standard linear development strategy:
It is always strongly advised to perform smoke testing following a CPQ deployment to production. Smoke testing should include two things:
Important Note
It is always recommended to have a rollback strategy so that if things go wrong in production, changes can be rolled back and business can continue.
Metadata changes, such as objects, fields, and workflows, can be easily migrated from one Salesforce instance to another using tools such as changesets for easy environments and DevOps and release management for complex environments. Record data containing relationships is not easy to deploy between different instances of Salesforce. We know that Salesforce allocates a unique 15- or 18-digit ID to each record we create.
We cannot maintain relationships between records when deploying changes through multiple development environments and then, finally, to the production environment. It's important to note that all CPQ configurations, such as product rules and price rules, are data records and not metadata, which makes CPQ deployment difficult. The metadata changes need to be deployed before the data changes. For example, consider deploying a price rule and associated metadata (for example, a new field). The new field needs to be deployed before deploying the price rule. For the price rule, you will have multiple records in multiple objects. You will have a price rule record, a price action record, and a price condition record, all of which need to be deployed.
Your organization should have several standard test scenarios that are used to test-exercise a system for errors and compatibility. These scenarios need to be executed before deploying the changes to production. This is included as part of the internal release schedule.
Let's look at a few guidelines for deploying CPQ changes from one instance to another:
In the next section, let's learn about another important concept, which is the CPQ data model.
CPQ uses standard Salesforce objects and CPQ objects. All the CPQ object API names start with SBQQ__, which identifies a specific object that is linked to Salesforce CPQ. All the CPQ field names that come out of the box are also prefixed with SBQQ.
In Chapter 1, Getting Started with Salesforce CPQ Implementation, we learned about the high-level CPQ object model. But that model was basic and didn't provide extensive information about all the objects and fields. CPQ is an enterprise-level application with more than 80 objects, 1,000 fields, 28 fieldsets, and 500 classes; the scale of the product is huge.
The most important and major Salesforce objects are products and opportunities. Most organizations, before implementing CPQ, might have customized these two objects heavily. As businesses grow further, they implement CPQ; so, we may need to decouple the existing customization in these objects and move the functionality to CPQ objects.
The following figure shows the object model for major objects:
Refer to the Salesforce help documentation for an exhaustive list of the lookup and master-detail relationships: https://help.salesforce.com/s/articleView?id=sf.cpq_object_relationships.htm&type=5.
For your specific implementation, you will be building a data model that will include major objects and their relationships. This is not a one-time activity; as part of your implementation progress, you can revisit these objects and/or their relationships as needed.
The Salesforce Schema Builder can be used for extracting a data model. You don't need the 500+ objects from the CPQ package and the thousands of fields to build the object model. But even for the objects that are needed for your implementation, this is a cumbersome task. However, this object model will be very useful, and you'll have an overview of the data structures. You can view the relationships between the major CPQ objects listed as follows using Schema Builder:
The detailed relationships between objects can be reviewed in many ways. Schema Builder is an out-of-the-box Salesforce tool that helps to visualize the object model. In the next section, let's learn about Schema Builder.
The Schema Builder is an easy and out-of-the-box Salesforce tool that helps you visualize an object model and its relationships. Navigate to Setup Quick Find Schema Builder. On the left-hand side of the panel, you can select objects and clear objects. You can also select specific objects whose relationships you want to display. Select View Options to display the field only with relationship; that way, you can get a simpler object view. Click on Auto-Layout to view all the selected options in the display.
The following figure shows a Schema Builder example with a few sample objects - opportunity, quote, quote lines, and products:
As you can see, Schema Builder displays the lookup and master-detail relationship between objects. You can choose standard and CPQ objects as needed. In this example, we are showing the relationship between Account, Opportunity, SBQQ_Quote__C, SBQQ__QuoteLines__C, and Product2 objects. This is a user-friendly and intuitive tool that can be used to understand the Salesforce object model very well.
Another method of creating a data model outside Salesforce is using Lucidchart. This provides an out-of-the-box integration to export Salesforce objects.
To do this, navigate to Lucidchart File Import Data Entity Relationship (ERD) Import your Data Import from Salesforce. Lucidchart will prompt you to connect to either a sandbox or a production instance. Provide the Salesforce credentials. Choose the objects that you want to import from the search window, as shown here:
Select the Show only relationship fields on each object option to display only the required fields. The objects will be added to the left-hand panel of the Lucidchart window under the Entity Relationship Diagram (ERD). These objects can be dragged and dropped to the chart. The following figure shows sample objects in a chart:
Once you import the objects, you can see a list of the objects on the left-hand side, and you can add objects as needed. The fields on these objects can be deleted to simplify the ERD view. Deleting fields from Schema Builder will delete them from the database.
In the next section, let's learn about data migration from legacy systems to Salesforce.
Data migration is the process of moving data from one system to another. Migrating legacy data to Salesforce CPQ has a few prerequisites to ensure that all dependencies are migrated accordingly. For example, if you are migrating a contract, the dependencies to the account and the initial opportunity need to be migrated before migrating contract data. If the account already exists in your Salesforce instance, then you will need to map the relevant properties to the Salesforce objects to auto-populate the account fields when you migrate the contract. While migrating, make sure that the field API values are not changed.
Data migrations need to be performed in a full sandbox for business validation and regression testing. Make sure that the test scenarios include historical data, new data, and in-progress (in-flight) data. Once the business validates and provides a sign-off, the same migration can be performed in production. When you have large historical data volumes, check with business stakeholders whether they need all the data to be migrated. Note that for businesses, the current fiscal year/quarter data is much more important than historical data.
Make sure that you check the amount of time taken to load the data to a full sandbox to estimate the production data load times. Communicate to business stakeholders in advance the implementation dates and possible downtimes (if applicable).
When importing data to Salesforce objects, we can use the external ID to prevent duplicate record creation. These are unique IDs for each record in your organization. External IDs can also help with moving data from one organization to another. The external ID keeps the original record ID in a field so that when we have records related to it, we can easily find them. But the drawback of using the external ID is that cloning will fail, as these are unique.
There are several steps that CPQ admins need to perform to maintain data integrity and manage these dependencies. Admins need to make sure that in the data migration, they are migrating the prerequisites for historical data and new data as well.
As the Salesforce platform is very flexible for exchanging data between internal or external systems, we have several tools for migrating legacy data. There is no right or wrong tool to choose for migration, and you need to choose the tool that best suits your migration needs. Some tools include the following:
Now that we know how to choose the best method of migration to import and export data, let's learn some of the important considerations for organizing and migrating data.
Data migration is always a complex process in CPQ implementation. Data quality plays a crucial role in a successful migration. Make sure data is validated in the test system thoroughly before migrating to the production system. A few important considerations in CPQ legacy data migration include the following:
One of the key concerns while migrating your data to Salesforce CPQ is to ensure its integrity and accuracy. Ignoring the quality of the data migrated will end up affecting all your business processes carried out using the concerned records.
Irrespective of the tool chosen, the migration process is implemented in sequence so that the prerequisites are migrated as required. For example, you cannot migrate opportunities without migrating accounts because you need the parent records to migrate any child records.
Each stage must be executed and completed before executing the next stage. Some stages are executed by an external Extract, Transform, Load (ETL) tool, and other stages can be executed directly in Salesforce using batch Apex or queueable Apex. Migration initially needs to be performed in a full sandbox environment where regression testing needs to be completed. Once the business validates and provides a sign-off, the same migration process needs to be executed in the production organization.
For example, if you have used a data loader to migrate the data in the sandbox, the same .csv file and data loader mappings need to be used for production migration. Additional records can be added to the .csv file based on the business. You may have loaded the contracts into the sandbox using a .csv file on January 1, 2021. The actual go-live date may be on January 15 after the UAT. Additional contracts that were generated in these 15 days need to be appended to the .csv file.
Alternatively, if you have used migration scripts, the same migration script needs to be executed in the production organization. Email deliverability needs to be turned off while migrating the data to production to avoid sending emails to users associated with the records. While using the data loader, verify the time zone of the target organization and make sure the data loader has been correctly configured.
Make sure the order of migration is determined correctly. You can decide your organization's object dependencies using Schema Builder. The following are the major stages in CPQ data migration:
Products and related records drive most of the CPQ functionality. Missing product data can break the functionality. The product metadata schema needs to be migrated completely. For example, when you are migrating a bundle, you need to make sure all the dependencies are migrated.
Field-level data, configurations, automation, and so on need to be taken care of. Do you need all the versions of the legacy quotes to be migrated? Think about an archival plan for old data.
CPQ migrations can take days or weeks. Involve sales teams/stakeholders. Close as many deals as possible for the CPQ implementation so that you will have a minimum number of open deals to migrate.
Identify Salesforce reports and a list view that might break and needs rework.
The timing makes a lot of difference. Avoid migration during the quarter end or the year end, where reps need to meet targets and close deals. For example, closed-won opportunities can be migrated automatically. After year end or by quarter end, we may have minimum in-progress opportunities, and these can be created manually to avoid errors.
When we don't have subscriptions in a legacy system, we need to gather the subscription data from external information and assets and create contracts in Salesforce. Test the renewal opportunity generation with a manual contract and product data.
When you have Salesforce contracts, archive contracts that you don't need.
Make sure that CPQ contract fields are added to existing contracts and create subscription lines.
These are some of the common stages. They can be modified, and other custom object migrations need to be included as needed.
In the next section, let's learn how CPQ can be used for multi-language requirements.
When selling your products in different countries, you might need to display the product information in a country-specific language. You may also need translations when you are selling in a country supporting multiple languages. Salesforce CPQ provides a localization functionality, extending the standard Salesforce metadata translations. CPQ also supports all the languages supported by native Salesforce. The Salesforce CPQ localization object provides translations for text, text area, long text area, and rich text area fields on the following objects:
Salesforce CPQ stores the translated values in a localization record. On the page layout of the record that needs to be translated, add the Translate button. For example, let's create translations for a product. Navigate to a sample product record in your Salesforce instance and click Translate. This will open the page shown in the following figure:
In this example, we navigated to the Loss and Damage Warranty product. Select the language to be translated; in this example, we selected French. For all the fields to be translated, provide the translated values, and save the record. In the previous figure, the Product Name field has been translated.
In this chapter, you learned how to extract and work with the Salesforce object model, which helped you understand object dependencies and relationships. We also saw the important role legacy data migration plays in the successful implementation of the CPQ project.
Migration may sound as simple as migrating data from point A to point B, but in this chapter, we realized that there are a lot of complexities involved in this process, and it is very challenging. We also realized that the data in each legacy system is different, and thus it is very important to understand the legacy data mapping to Salesforce CPQ objects. We learned how CPQ changes can be migrated from one Salesforce instance to another. There is no right tool that fits all migration needs. Based on the business process and the functionality, the solution needs to be analyzed and implemented.
In the next chapter, we will learn about Salesforce Billing.