How to Leverage Customer Object in SAP CPQ
9 min read
CX community knows SAP CPQ (Configure Price Quote) mainly as a prominent part of Quote To Cash and Lead To
Cash processes where it integrates with systems like SAP Sales Cloud Solution, SAP Commerce and S/4 HANA. The
application's way of dealing with customer data in this case is, naturally, adapted to the specific business
flow of the process - customer data is obtained from external systems and displayed in SAP CPQ.
SAP CPQ also functions as a standalone application and is sold in such a package too. In that case it does storage and manipulation of complete customer data on its own.
Table of Contents
Two Types of SAP CPQ Customer Objects
Every customer in SAP CPQ is either a Local or Global customer. Local customer is owned by a particular SAP CPQ user and is, by default, visible only in the user's working scope. Global customers are global object, potentially visible and available to all SAP CPQ end users.
Global customers are intended to be created in administration pages for Customers as demonstrated in the
Local Customers are meant to be created and manipulated in end-user side. Add option in the quote page might be a way to do that as demonstrated below:
Alternatively, the Manage Customers section available in User pages is another option:
Both customer types can also be created or updated through Excel Imports/Exports, or through SAP CPQ APIs. With APIs it is just a matter of entering the owner id, if the goal is to create a local user. There are other means to create customers, like using "Create Customer Object" option in companies setup or by creating and assigning customers in scripting - but the main business cases were listed above.
The idea of local/global differentiation is that by default one sees its own (local) customers only and by adding visibility rules certain global customers or local customers belonging to other users can become visible too. A customer of any of the types can be assigned to roles in your quote, if it is visible in the customer search box. More on visibility rules for local customers can be found here, while for global customers, more info is here.
One will be able to edit his own local customer in quote, if Edit action is set as available in
administration pages (here is more on customer actions). So, update of the local customer in quote is update to
the local customer object too and will be reflected to other quotes using the same customer object. Still, be
wary that there is an exception applied to customers assigned to Ship To role in quote - Ship To customer
updates are not shared between quotes. More on this is given below.
Even if the Edit action is available, one will not be able to apply to a global customer used in quote, and the same applies for another person's local customer. This is applicable always for Responsive SAP CPQ while for the older, Classic SAP CPQ, there was an option to change the behavior by controlling a parameter value.
All other systems that maintain customer data deal with customer roles and SAP CPQ is not an exception. Three
different roles exist in the system - Bill To, Ship to and End User (or End Customer). End User is deactivated
by default and can be turned on by controlling an application parameter value. The three roles do not have
identical functional behavior and few paragraphs will be spent to outline the differences.
Bill To and End User Customer selections in quote are stored as references
to either global or local customer objects in the system, while Ship To is just a database record copied and
stored for that quote only, without maintaining the reference to the shared object. This means that if you
select a global or local customer for Ship To role in your quote, you can modify the data but none of the
changes will be reflected to the original customer object and will stay on quote level only. The same
applies in the opposite direction - if you modify a global customer object which was selected for a quote
Ship To, the Ship To info will stay unchanged (contrary to Bill To and End User). Also, if you use Add
action to enter a new customer for the Ship To role in your quote a new local or global customer object will
not be created.
Bill To and End User, in contrary, maintain the references and if you can modify the customer data, the changes will get pushed to referenced objects too. Try, for example, to copy Bill To customer data to End User in the same quote - if you change any value for Bill To, the change will immediately get pushed to the End Customer. The vice versa applies also.
If you add a new customer in quote, from Bill To or End User forms - a local customer object will be created as soon as you click Save. The described difference between the roles is the consequence of specifics of Ship To use in the general SAP CPQ business use case. Another ramification of this is that customer search in quote (the Lookup action or just use of the search box) is actually a search against Bill To/End User customers' data (and customer objects potentially unassigned to any quote yet). If you have entered some specific Ship To data in another quote, that Ship To customer object will not be available in search in general.
Integrations with CRMs
The question is now how SAP CPQ customer object behaves when the system is
integrated with master customer-data systems. The solution for this was obvious - SAP CPQ was built to
enable the ownership shift to the external systems. The standard integration user journey establishes a link
between CRM quote and SAP CPQ quote and user usually lands to the SAP CPQ quote from an opportunity or the
At the moment of landing, SAP CPQ usually pulls the selected-customer data from CRM and maps it to the standard SAP CPQ customer roles in the quote. In the background, local customer objects, assigned to the current SAP CPQ user are created. If another quote gets created with the same customer data in CRM and progressed to SAP CPQ, SAP CPQ will identify an existing local customer and assign that one to the new quote also. If the CRM customer data source was altered, but not more was changed than what SAP CPQ needs to match two customer data sets (by applying several criteria), a matching SAP CPQ object will be identified and updates applied to it also.
We have two different interfaces for CRM integrations - one that applies to all other systems (SalesForce, Microsoft Dynamics, NetSuite, Oracle, ...) and one for SAP CPQ as part of Lead to Cash, when SAP CPQ integrates to SAP Sales Cloud Solution. You can find settings for the first group in "CRM Administration" section of SAP CPQ setup:
Under Customer Roles Mapping you decide how exactly mappings are going to get executed:
In the screen, you can see that you decide which of SAP CPQ customer objects is going to get instantiated and which Account and Contact objects in CRM side are going to be used as data sources.
With this integration it is also possible to make updates in CRM, initiated by SAP CPQ, but the customer data sync from CRM to SAP CPQ represents the standard data flow.
The setup is uniform for any CRM in the group that SAP CPQ integrates with and more of the official documentation you can find here.
With Sales Cloud, the approach is a bit different. The administration-level setup is in Providers section (see image below) and here you do not set any parameters of customer mappings. Those live in CPI artifacts and for the Sales Cloud integration, the CRM account information is used to instantiate a local Bill To Customer. CRM Ship To data is used to instantiate Ship To customer object in SAP CPQ quote.
You can read more technical details on SAP CPQ - SAP Sales Cloud integration here.
SAP CPQ has a customer-object model of its own and can operate independently. Still, when integrated to master customer-data systems, CPQ can give primacy to the other system. The primacy relates to master data location, while SAP CPQ customer objects will keep being instantiated to maintain the CRM data.
There are many specifics of the SAP CPQ customer object coming just from its own history, which rises in complexity when combined with specifics of individual integrations. This is why it is important to be familiarized with detail-level characteristics, if you are to execute a SAP CPQ implementation.
Do note that the goal of this article was not to give full technical
specifications on SAP CPQ customers in the way our official documentation does. The goal was to put focus
on the object specifics that newcomers usually stay unaware of, even after executing several SAP CPQ
projects and also to give that in a digested, shortened form.
If you are to engage with SAP CPQ implementations, it is recommended to read the official documentation too, as many topics where just briefly touched here.