Salesforce CPQ is unquestionably an invaluable tool for sales teams, helping them streamline the process of configuring complex product offerings, pricing them accurately, and generating quotes efficiently. But how can CPQ admins make the best use of the tool from the backend side of things? 

In this blog, you’ll learn what twin fields are, explore their use cases, and find out how you can use Salto to improve their deployment and ongoing maintenance. 

What are Twin Fields?

Twin fields are exactly how they sound - they are pairs of fields, created on multiple objects, to  help with maintaining data integrity and consistency across various objects. They are useful for ensuring that data remains accurate and synchronized, particularly in complex configurations where maintaining identical data points across multiple records is vital. For example, if you have information on the Quote Line Item, you likely want that same information on the Order Product level, and possibly even the Opportunity Line Item. 

‍

Under normal circumstances, an admin would need to create the fields and then create an automation to map the data between them, using Flow or code; but with twin fields, Salesforce CPQ has already built the mechanism to map the data between certain objects automatically. 

Twin fields work by creating a mirrored relationship between two (or potentially more) fields across objects. This means that any update or change made to one field is automatically reflected in its twin, ensuring both fields hold the same data. 

Let’s say you capture a configuration attribute when configuring your product in Salesforce CPQ, such as the amount of online storage your customer is entitled to as part of your backup solution. This could be one of many configuration attributes, and you would like to maintain this information on the quote line after the configuration is complete. 

You can create a twin field between the configuration attribute object and the quote line object and Salesforce CPQ will automatically ensure the values are synchronized. Furthermore, if you wanted to maintain this attribute information on the Subscription object, you could create another twin field which would also be automatically synchronized with the value on the Quote Line. 

‍

‍

Why Does Salesforce CPQ Use Twin Fields? 

Now that we’ve covered what twin fields are and how they work, it's the perfect time to explain their usefulness in Salesforce CPQ. 

Data Integrity and Seamless Integration

Critical data must remain accurate and consistent across multiple objects if you want your quotes and product configurations to be accurate. Without twin fields, discrepancies can arise between different records. 

Without Twin Fields:

• A product is configured with a configuration attribute that captures the selected color of a product. 
• The Quote Line Item has this information, but there is no twin field passing it to the Order Product. 
• The Order Product object is the one integrated with your fulfillment tool, and when the Order arrives, the team has to constantly email the sales team to find out which color a customer ordered, leading to possible errors and time wasted. 

With Twin Fields:

• Once the Sales rep configures the product for the customer, all configuration information, including attributes are automatically synchronized between the Quote Line Item record and the Opportunity Product record. 
• This results in the order fulfillment team being able to proceed efficiently with each order, saving time, money and improving the customer experience. 

After looking at the potential issues that can arise without twin fields, the value of using twin fields in Salesforce CPQ becomes clear. 

Differences from Cross-Object Formula Fields

If you’re an experienced Salesforce Administrator, you might be wondering why you can’t just use a cross object formula to achieve the same result as Twin Fields. Although cross-object formula fields can be used in a similar way, i.e. you can simply create a text formula field and directly pull the value of a field on one object to another, however, this method poses limitations that Twin Fields avoids. 

Static vs. Dynamic:

• Twin Fields: Store static values that need to be consistent across records. These values are entered manually or through automated processes and do not change unless explicitly updated, such as the color attribute selected for a chosen product. 
• Cross-Object Formula Fields: While Cross-Object formulas can be used similarly to twin fields, they also can calculate values dynamically based on other fields. The value of a formula field can change automatically when the referenced fields are updated.
  
  For example, a sales rep might select a color by name during product configuration, which is saved to the quote line record. On the Order Product record, that value is then translated into an alphanumeric color code, which is used to automatically fulfill the order downstream. 

Consistency vs. Calculation:

• Twin Fields: Ensure consistent data across different records. They are crucial when identical data points must be maintained, such as product codes or pricing information across various quotes and contracts.
• Cross-Object Formula Fields: Used for on-the-fly calculations and can reference fields from related objects. They are ideal for scenarios where you need real-time calculations, such as calculating the total price of a quote based on the sum of line item prices.

Use Case Specificity:

• Twin Fields: Best used when you need to ensure that specific data points remain identical across different records. This is critical in maintaining data integrity during data migrations or integrations with other systems.
• Cross-Object Formula Fields: Useful for creating dynamic data points that depend on other fields. They simplify complex calculations and automate data updates without manual intervention.

Limitations of Cross-Object Formula Fields 

Salesforce allows a maximum of 10 unique relationships per object in cross-object formulas. The limit is cumulative across all formula fields, rules, and lookup filters. For example, if two different formulas on opportunities reference two different fields of an associated account, only one unique relationship exists (from opportunities to accounts).

Formula fields are also unable to be history tracked, meaning any Cross-Object formula field would not be able to be history tracked by default. You also cannot have a Cross-Object formula field that references a value that is calculated by a formula field. 

Cross-Object formula fields do have their uses, but when it comes to passing data between Salesforce CPQ objects specifically, twin fields are a much better resource without the limitations posed by formula fields. 

Use Cases for Twin Fields

Twin fields in Salesforce CPQ provide specific advantages over cross-object formula fields and other automations like flows. Here are some detailed examples illustrating why you’d use twin fields:

Product Configuration Sync

Scenario: When configuring product bundles, it is essential to keep related product data synchronized across quotes, orders, order products, contracts, subscriptions and more.

Without Twin Fields:

• Product configurations can become inconsistent across different records, leading to incorrect product setups in quotes. For instance, if a product's feature list is updated in the product catalog but not reflected in the quote line items, the sales team may present outdated product configurations to customers.

With Twin Fields:

• Twin fields ensure that the product configuration, pricing, and other critical data remain identical across all related records and objects. When a product feature is updated in the catalog, the twin field ensures the same update appears in all related quotes and contracts, maintaining consistency and accuracy in product configurations

Billing Consistency

Scenario: Maintaining consistent billing information across various sales documents is critical for accurate quoting.

Without Twin Fields:

• Pricing fields on the quote line could appear differently on billing records such as the order and invoice if pricing information is not carried over from quote and/or opportunity records. Discount information could also be lost if not carried over correctly, resulting in an incorrect invoice or charge to the customer, resulting in unnecessary customer complaints. 

With Twin Fields:

• Any update made on quote lines is automatically pushed to the order product, and subsequent invoice records if applicable. This ensures customers are billed accurately, every time, resulting in happier customers and improving revenue.  

Data Migration and Integration

Scenario: Synchronizing data between Salesforce and external systems requires consistent and accurate data. 

Without Twin Fields:

• Data inconsistencies can arise during integration if values are not synchronized across Salesforce CPQ. For example, if the Order Product object is synchronized with your fulfillment tool, but it’s not being updated in line with the Quote Line, there could be issues when processing an order, especially if a customer asked for a last minute change, such as a different color, or even a shipping address change. 

With Twin Fields:

• Twin fields ensure that critical data points, such as pricing and product configuration information, are maintained across all relevant objects in Salesforce. This makes data migration and integration more reliable and error-free, as twin fields maintain consistent identifiers across systems​ 

Contract Management

Scenario: Managing contracts that involve multiple related records requires consistent data to avoid discrepancies.

Without Twin Fields:

• Inconsistent data can lead to incorrect contract details, causing potential legal and financial issues. For example, if the terms of a contract are updated in one record, such as the payment terms, but not reflected in related contract records, it can result in conflicting contract terms and potential customer issues. 

With Twin Fields:

• Twin fields ensure that all related records, such as contract terms and pricing, are consistent across the board. This reduces the risk of errors and ensures that all contract details are accurately maintained, supporting reliable contract management​.

By understanding these detailed use cases, it becomes clear that twin fields play a vital role in ensuring data consistency and accuracy across various Salesforce CPQ processes. They offer significant advantages over other methods like cross-object formula fields and flows, particularly in maintaining static data consistency and supporting complex configurations.

‍

Twin Fields Setup Guide  

Setting up Twin Fields is simple. A good place to start is by reviewing the official Salesforce Knowledge article on twin fields, to know exactly which objects are “twinned” with each other. 

‍

These mappings include, but are not limited to: 

• Quote Line to Opportunity Product
• Quote Line to Order Product
• Quote or Order
• Asset & Subscription to Quote Line (in cases of renewals or amendments)
• Quote Line to Asset & Subscription
• Configuration Attributes to Quote Line

‍

The next step is to simply create the fields required on the required objects, most importantly with exactly the same API name. This is the key component to ensuring the twin fields are recognized by Salesforce CPQ’s out of the box feature that automatically maps the values between the defined objects. 

‍

Another important thing to note is that users must have Read access on all twin fields to ensure they are populated across objects. What this means in practice is that all users who use CPQ should at least have Read access to every twin field, across all Salesforce CPQ objects. Without this, fields may not be populated, depending on how related records are generated. 

‍

For example, if a sales rep closes an Opportunity, and off the back of that, there is an automation, running as the sales rep, that creates the Order record, the Order won’t have the twin fields copied from the Primary Quote if the sales user doesn’t have access to the twin fields on the Order object. The information will not be copied over and once this lack of data is realized, the information will need to be manually filled in for every affected record. 

‍

This can lead to mass data inconsistencies across the platform if permissions are set up incorrectly, so make sure this set up is correct before putting any Salesforce CPQ functionality live! 

‍

How Salto Can Help With Deployment of Twin Fields

Salto is a dedicated tool to deploy Salesforce CPQ metadata and data. Due to the complicated setup of Salesforce CPQ, specialized tools like Salto make deploying Salesforce CPQ simple and straightforward. While Twin Fields are classed as “metadata”, Salesforce CPQ also relies heavily on data deployments with complicated relationships to be deployed smoothly, to avoid disrupting users' use of the platform. 

Salto analyzes your deployments to ensure you are deploying everything, in the correct order, and alerts you if you’re missing anything crucial, something you don’t get with a basic data loading tool. The analysis can be crucial, for example, if users don’t have access to the right fields, data can be lost throughout the system and require extensive and time consuming manual backfilling once the issue is caught. 

Summary 

In summary, Twin Fields are an extremely useful feature built into Salesforce CPQ’s arsenal of tools designed to ensure data consistency across not only Salesforce objects, but also downstream applications as well. When used correctly, Twin Fields provide a quick and easy way for admins to get data exactly where it needs to go, without having to build and maintain automations that push data to the relevant objects with Salesforce CPQ. 

Additionally, tools like Salto can help you get the most ROI out of your Salesforce CPQ implementation, as well as helping you deploy complex data with ease. Try Salto for free today to elevate your Salesforce CPQ experience!