You are here:
Picklists and Attributes in EPC
Products may or may not have attributes. A product that does not have attributes comes only in one form, and customers do not make any decisions about the features of the product, such as a headset or a computer cord that come in one color.
If a customer can choose from a selection of product features, you must define these features as attributes before creating an object type. Also, if an attribute includes multiple values that a customer can choose from, you must define picklists before defining the attribute.
Product attributes provide a powerful and flexible way to extend product entities. Product attributes are stored in an aggregate JSON blob on the Product object. They are used extensively throughout Industries CPQ and Order Management.
Uses of Attributes
In Industries CPQ, you can use product attributes to filter products at runtime, displaying the best-fit products to customers. You can use them to configure product specifications, allowing users to specify product colors, sizes, and other options. You can also use attributes to change product pricing using attribute-based pricing rules.
Finally, in Order Management, you can use attributes to map commercial products, or the products that customers see, with technical products that communicate with backend systems to fulfill the products that are purchased.
In the above diagram, the object is a smartwatch with various attributes, shown on the right. The provisioning process requires the definition of the attributes, such as size and data capacity to cater to customer preference.
When a customer orders an offering based on the smartwatch object, such as an Apple Watch Series 5, you can think of it as a collection of statements that describe what they are ordering.
Attribute |
Value |
|---|---|
Brand |
Apple |
Band type |
sport band |
Band color |
gray |
Capacity |
8 GB |
Product width |
38mm |
Operating system |
watchOS 4 |
Feature |
GPS |
International Mobile Equipment Identity (IMEI) number |
assigned during provisioning |
When a customer orders an offering derived from the Base Commodity object, such as a Unit Rate for electricity, you can think of it as a collection of statements that describe what they are ordering.
Attribute |
Value |
Description |
|---|---|---|
Usage Price |
0.13673 |
Price per unit of energy consumed |
Usage Attribute |
5463 |
Estimated usage, such as average kWh/month |
Usage Price Total |
746.96 |
Usage Price multiplied by Usage Attribute |
Usage Margin |
5.18 % |
Percentage of Usage Price that is the profit margin |
You do not want to redefine all of these statements each time a customer orders a product. Instead, you want to reuse attributes and the definition of a product. Some of these attributes are set during design-time, some at runtime, and others during order decomposition (provisioning).
With Salesforce Industries EPC, you create attributes once and assign them to an object type for the product. For example, Google and Apple smartwatches could both have the object type SmartWatch, each with a different set of attributes. Having this structure in place helps the CSR support customers by giving them the correct product details and place consistent orders.
Overrides
Although you cannot delete any inherited attributes or fields, you can override them at the product level. In the SmartWatch example, you could override the color picklist inherited from the SmartWatch object type to include colors that are specific to the Series 3 Apple Watch. In the Unit Rate example, you could set the Usage Attribute to a typical residential consumption value and then override it with a more fine-tuned estimate.
You can also add additional attributes directly to the offering level.
Attributes vs Fields
-
Attributes: A list of all attributes and their associated Attribute Codes assigned to the Product2 Object.
If a data element, such as a SKU number, is intended to be common to all products across your product catalog, then you should create a new field on your product object. Typically, adding new fields requires Salesforce system admin privileges.
-
Fields: A list of all fields and their associated Field API name for the Product2 Object.
If the data element is intended to be specific to a product, or class of products, then you should create an attribute, such as download speed. At runtime, attributes are visible to customers in Industries Cart and can be used to filter the catalog and provide configuration capabilities. Adding attributes requires access to the Product Console.
The fundamental differences between fields and attributes are:
Fields |
Attributes |
|
|---|---|---|
Where the value is created? |
Created in Salesforce Setup on a Salesforce object. Field example: Orderable. |
In attribute/category interface. Attribute example: Color. |
Where the value is stored (including metadata, such as default value, picklist, etc.)? |
Each field value is stored in a separate Salesforce field. Related metadata is stored separately in Salesforce. For example, if you create 15 fields, there will be 15 field records in Salesforce and each record will store its value. |
Each attribute value and its’ metadata (including picklists, default value, etc.) is stored in a JSON blob (i.e. in a FIELD in JSON). For example, if you create 15 attributes, all 15 attributes and all their metadata will be stored in one JSON blob which is stored in one Salesforce field. |
Who can create? |
Requires Salesforce System Administrator privileges. |
A Product Manager with sufficient privileges. |
Is searchable at runtime? |
Each field is stored in a separate Salesforce database field and is easily searchable. |
Since all attribute data is stored in one JSON blob, expect performance implications when using search. |
When to use at design-time to define Product2 properties |
Use for commonly used properties that are searchable and runtime (order time) configurable. |
Use for properties that are sparely used. |
When to use at runtime to define asset properties |
Do not use. |
Use attributes only. For example, IMEI number, VIN #, etc. |
- Create Picklists and Picklist Items in the Product Designer
A picklist is an ordered list of values that customers can choose from when buying a product. If an attribute includes predefined values, a picklist represents all available values for that attribute. You can reuse picklists across attributes assigned at the object type level or the product level. - Create Attribute Categories in the Product Designer
Use attribute categories to group product attributes. They also appear as headings at runtime in Industries Cart’s Filter and Configuration windows. - Define Attributes in Product Designer
A product attribute is a characteristic that defines a particular product and affects a consumer's purchase decisions. Attributes can include product characteristics such as make, color, bandwidth, and storage. - Create Attribute Bindings for Usage Pricing
In a unit rate cost component, the Usage Price Total field value is the Usage Price field value multiplied by the Usage Quantity field value. Making an attribute editable in Industries Cart is much easier than making a field editable. Therefore, to set the Usage Quantity value from within Industries Cart, creating an attribute binding is strongly recommended. - Encrypted and Not Assetizable Attributes
In the Product Designer, you can flag attributes for technical products as not assetizable and encrypted. After these attribute metadata flags have been set on an object type and inherited by a product, you must create decomposition rules to map the attributes to the downstream fulfillment requests, which are the basis for the technical inventory. - Attribute and Picklist Overrides for the Object Type and at the Product Level
An attribute can be associated with a picklist that has possible values for the attribute. You can set the default value of an attribute. When you associate the attribute with an object type, child object types and products inherit the attribute but can override it.
