The GUID performance feature is an optional performance enhancement. When enabled, the feature eliminates an expensive write operation from many common customer transactions, such as add-to-cart.
The existence of an ID value within the RootItemId__c and ParentItemId__c fields in the without-GUIDS case usually requires a separate DML to write after the DML that created the line items. The reason for the additional DML is that the ID values of the target line items are usually not available until after the write operation that created them is finished. This second write is not necessary when you enable the GUIDs performance feature unless you are creating new line items within containers that have not been converted to the new style because the new values are not Salesforce IDs.
In addition to immediate time savings, the GUIDs performance feature carries other benefits for the future, allowing existing features and to-be-developed features to potentially run faster by enabling them to issue minimal write operations (one). Also, the savings of the DML can have cascading benefits for other database operations on the same Salesforce org by reducing the overall database workload.
DMLs can be very expensive to execute so even though this change does not come without potential migration issues, the benefit is substantial both in immediate time savings and reducing the load on the database in general.
It is not possible to accurately quantify the time savings enabled by this feature because observed times for the affected write operations vary widely depending on factors such as the exact structure of the product being added, load on the Salesforce org, and many other conditions.
Impact of Enabling GUIDs
Enabling the GUIDs feature impacts the following line item and asset types stored in the RootItemId__c and ParentItemId__c Vlocity-defined fields:
-
Asset contained within an Account
-
OrderItem contained within an Order
-
OpportunityLineItem contained within an Opportunity
-
QuoteLineItem contained within a Quote
For example, consider a simple product hierarchy with a root product named "Root Product" and a single child named "Child Product. The line items, which could be OrderItems within an Order container, but in fact could be any of the above types, might appear in the database without the GUID switch enabled:
|
ID |
AssetReferenceId__c |
Name |
ParentItemId__c |
RootItemId__c |
|---|---|---|---|---|
|
8024600000Nj76BAAR |
77be5715-a534-cd6f-d634-7a23518de2be |
Root Product |
NULL |
8024600000Nj76BAAR |
|
8024p00000NDeLWAA1 |
29465e8f-6521-794b-0f66-2ce1d93d4991 |
Child Product |
8024600000Nj76BAAR |
8024600000Nj76BAAR |
These are not all the fields present, but these are all the fields relevant to the GUID feature changes. The ParentItemId__c values, when not null, and the RootItemIdValues__c all match the target Salesforce ID (“Id”) of some row in the container. The ParentItemId__c points to the ID of the immediate parent in the hierarchy and the RootItemId__c field points to the line item at the root of the hierarchy. The AssetReferenceId__c field value is not entirely relevant at this point, but it becomes relevant as you explore the with-GUID state of the records.
Consider the state of these same records as they would exist if written into an empty container with the GUID feature enabled:
|
ID |
AssetReferenceId__c |
Name |
ParentItemId__c |
RootItemId__c |
|---|---|---|---|---|
|
8024600000Nj76BAAR |
77be5715-a534-cd6f-d634-7a23518de2be |
Root Product |
NULL |
77be5715-a534-cd6f-d634-7a23518de2be |
|
8024p00000NDeLWAA1 |
29465e8f-6521-794b-0f66-2ce1d93d4991 |
Child Product |
77be5715-a534-cd6f-d634-7a23518de2be |
77be5715-a534-cd6f-d634-7a23518de2be |
Note that the ParentItemId__c and RootItemId__c values no longer match the target line item’s ID field but instead match the target line items’ AssetReferenceId__c field. The hierarchy defined is the same in both cases, without GUID, and with GUID, but the type of value within the hierarchy fields is different.
Also, note that neither the GUID nor without GUID examples mix the value styles. There is not, for instance, one-row using Salesforce IDs and another using AssetReferenceId__c values in the two fields. Line items or assets in a single container do not mix styles even with the GUID switch on.
The ParentItemId__c and RootItemId__c fields point to the AssetReferenceId__c value of the relevant line item in the hierarchy instead of the Salesforce ID of those line items.
Handling of Legacy Records
You do not have to migrate legacy records in the customer database that contain values written before you enabled the GUID switch because those records already have proper functionality. However, if you proactively change the records to the new style, more types of transactions, including MACDs writing to older-style accounts with older-style assets, experience the performance benefits of the GUID feature. Salesforce Salesforce provides customers with a background job capable of making these changes proactively.
Once you enable the GUID switch, existing containers are not immediately converted to the new data format. Instead, Vlocity code can detect and handle either of the two formats to allow proper functionality while existing data is migrated using the supplied background process (or not, the migration is optional).
Custom Code
Ensure all such custom code is inspected and modified before enabling the GUID feature. It is possible that a customer installation has code that is sensitive to this change.
- Enable GUIDs for Industries CPQ
To enable the GUID performance feature: