When should you choose to use an attribute rather than a field when creating a product in Vlocity CPQ?

In Industries CPQ (Vlocity CPQ) , an attribute should be used when describing a product characteristic that is not used in pricing or configuration rules. For instance, an attribute could be used to describe the color of a product, the size of a product, or the material a product is made of. These are characteristics that are useful to know about a product, but they don’t affect the pricing or configuration of the product.

On the other hand, a field should be used when describing a product characteristic that is used in pricing or configuration rules. For example, a field could be used to describe the product’s weight, which is used in calculating shipping costs or the product’s dimensions which can be used to configure a product. Additionally, fields can be used to store information that is used in configuration rules, such as the product’s warranty or the number of units that can be purchased in a single order.

Attribute	Field
If the data element is specific to a product or a class of product, create a product attribute.	If the data element is common for all products across the entire product catalog, create a new field on the Product object.
OOTB, attributes are used at run-time (visible to customers) in the Cart to filter the product catalog and to provide product configuration capabilities.	Typically, adding new fields requires Salesforce Administrator privileges.
Adding attributes simply requires access to the Product Console.

An example of using an attribute in product creation in Vlocity CPQ would be to describe the color of a product. For instance, you could create an attribute called “Color” and assign the possible values of “Red”, “Blue”, “Green”, “Yellow” and so on. This attribute could be used to display the color options available for a product on the product detail page, but it would not affect the pricing or configuration of the product.

An example of using a field in product creation in Vlocity CPQ would be to describe the weight of a product. For instance, you could create a field called “Weight” and assign a numerical value to it, such as 10 lbs. This field could be used in pricing rules to calculate shipping costs based on the weight of the product, or it could be used in configuration rules to determine the options that are available for a product based on its weight.

The following are the primary distinctions between fields and attributes:

	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.)?	There is a separate Salesforce field for storing each field value. In Salesforce, related metadata is kept separate. For instance, if you create 15 fields, Salesforce will contain 15 field records, each of which will contain a value.	A JSON blob is used to store each attribute value and its associated metadata, such as picklists and default values (i.e. in a FIELD in JSON). If you create 15 attributes, for instance, all of those attributes and all of their associated metadata will be stored in a single JSON blob that is kept in a single 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.

Hope this information helps you guys.

Cheers!!!

Mukul Sharma