Discover Object Types
Learning Objectives
After completing this unit, you’ll be able to:
- List the benefits of product object types.
- Explain how object types work in Product Designer.
- Describe how to organize data elements using object type layouts and sections.
- Explain how object type inheritance works in Shared Catalog.
- Summarize how different industries use object types to model products.
Reusable Product Types
Devi Jacob, the product designer at Infiwave, is getting familiar with Shared Catalog. By using Product Designer, he’s already created the picklists and attributes that serve as foundational components for building products.
The next step is to put these components to work by adding them to object types—the reusable entities in Shared Catalog. This way, Devi can quickly build out entire classes of products that share similar characteristics. As he soon learns, with a solid hierarchy of object types in place, assembling new product lines in the catalog is quick and easy.
Product Object Types
A product object type is a reusable entity that defines the schema of a particular category of products. You can use object types to apply layouts and properties, including fields and attributes, to multiple products in the catalog. Object types are a great way to organize the configurations of related products and to ensure consistent application of data, behavior, and rules across a product line. You can even create subtypes of object types to accommodate more specific product information.
So how do you configure and use an object type? To configure it, add and organize all necessary metadata, including fields and attributes for a specific type of product on the object type. To use the object type, create a new offer or specification (spec), and apply the related object type through a lookup field. The product automatically inherits the object type’s layout of metadata. This saves you precious time when configuring data for new products.
Here, you see the Details tab on the product screen for a Infiwave tablet offering.
The Object Type is set to Tablet so that the product inherits the layout from the Tablet object type.
Layouts and Sections
Object types contain layouts, which hold product attributes and fields. Think of a layout as a page template that lets you organize product data visually. You can configure sections in a layout to group elements into logical arrangements. Sections have descriptive headings and display elements in either one or two columns.
Here’s the Layout Management tab for an object type.
The tab has four sections: General Properties, Effectivity, Design Time Attributes, and Run Time Attributes. Each section contains a set of fields and attributes.
Object Type Inheritance
We now look at how data inheritance plays a part in creation of object type and products. In Shared Catalog, you use inheritance to construct categories and subcategories of products.
Check out this diagram of the Shared Catalog inheritance model. It’s like looking at a chart that shows the evolution of a species or a family tree.
The Product2 object contains object types, subtypes, and products. The layout of attributes and fields in the first level, or base object type passes down to object subtypes in level two, and then finally to the products that you create with each of those subtypes. Explore each of these layers in detail.
Product2 Object
The Product2 object contains the hierarchy of object types that store product information in Shared Catalog. Product2 is the default Salesforce object. Objects in Shared Catalog are a bit like Salesforce record types, but with enhanced capabilities. In Industries Configure, Price, and Quote (CPQ), Product2 is the primary object that holds all of the product records. Any fields you include in Product2 are present on the initial configuration screen when you create a product.
Why is the default Salesforce object called Product2? It’s a long story, but essentially, many years ago, Product2 was introduced to eliminate some issues with the original Product object, which has since been retired, and the name just stuck.
Base Object Type
Before you launch into creating object types for your products, we highly recommend you spend a few minutes creating a base object type. The base object type is the primary object type that contains all of the fields you’d like to be common across every product in your catalog. These might include fields like Product Description, SKU, or other common information to match your business goals. To learn the differences between fields and attributes, and when you should use each, refer to the Industries Picklists and Product Attributes module on Trailhead.
Object Subtypes
When you have the base object type in place, you can create subsequent object types, and set them to automatically inherit the configuration of the base object type. You can then tailor subtypes of these configurations as needed to reflect your company’s product categories with additional fields and attributes. And on it goes down the hierarchy. You can create subtypes of subtypes with increasing complexity to templatize the required information for each of your product lines.
Industry Object Type Hierarchy Examples
You can create object type hierarchies that match your specific industry and product model. Here are a few examples.
Communications
Communications service providers, their partners, and suppliers generally follow the TeleManagement (TM) Forum’s Shared Information Data (SID) model when using Shared Catalog. This model employs reusable product, service, and resource specs.
In this diagram, the object type hierarchy contains base object types that match each of these spec types.
In this example, product, service, and resource object types act as templates for creating specs for DSL Modem, Cloud Storage, and IP Address. There’s also a simple Base Bundle Offer object type, which stores common data for bundled products.
Media
This diagram shows how some media companies set up object types to streamline the creation of TV products.
In this example, a TV object type contains TV Plan, TV Channel, and TV Equipment subtypes. Unlike the TM Forum SID model, the product designer applies these object types directly to sellable offers, instead of specs. A TV Bundle product uses a Base Bundle Offer object type.
Energy and Utilities
This diagram shows how some energy & utilities companies set up their object types and subtypes in Enterprise Product Catalog (EPC) to accelerate the creation of commodity, charge components, unit rates, and devices.
In this example, a Base Commodity object type contains three subtypes: Standing Charge Component, Unit Rate Component, and Device. The product designer applies these object types to Standing Charge, Unit Rate, and Smart Meter products, respectively. A Clean Energy Bundle inherits the metadata from the Base Commodity object type.
Infiwave Smartwatch Example
Devi knows that Infiwave’s new smartwatch product shares many of the same characteristics as other mobile devices in the catalog, like smartphones. He maps out a quick diagram to guide his work.
Devi begins by creating a subtype of the Base Product object type, and names it Mobile Device. This subtype inherits all the standard fields contained within the base object type. In this new subtype, he assigns all the attributes specific to mobile devices, like Brand, Color, Capacity, Connection, and Mobile OS.
Next up, he creates the Smartwatch object subtype and sets Device as its parent object type. Again, the fields from the base product’s layout along with the additional fields and attributes present in the Smartphone object type automatically transfer to the new subtype.
As you can see in the image, Devi then adds the attributes he created for smartwatch products, such as Band Type and Connectivity, to the subtype.
What if Devi forgot to include a field or attribute in the parent Device object type after he’s built out the Smartwatch subtype? No problem. Fields and attributes assigned to parent object types update dynamically in the existing subtypes. But, there’s a catch. Salesforce employs an important guardrail to maintain consistency across the object type hierarchy. So, to remove any inherited components from a parent object type in the subtype, Devi must either delete the components in the parent object type or deactivate them at the product level.
Layout inheritance works slightly differently. While subtypes inherit attributes and fields dynamically, they inherit layouts and their sections via deep copy. This means that subsequent changes to the parent object type’s layout don’t replicate down the hierarchy after initial creation. The benefit here is that you can add or delete fields or attributes from the parent object type layout without having to worry about altering the fields or attributes of existing child object types.
After Devi has set up his object types, the final step is creating the product record for the Infiwatch that is sold to customers. By connecting the Smartwatch subtype to the product object, he creates an instance of the object type. With this ability to quickly apply preconfigured layouts, attributes, and fields, creating this and any other future smartwatch product objects is a piece of cake. “Hurray cake!” he cheers.
Now you have a basic idea of how object types and subtypes work in Shared Catalog. In the next unit you learn how to set up these flexible, time-saving entities in Product Designer.
Resources