Product Types
Many eCommerce customers face a challenge: they have many different kinds of products. While several shared fields exist between the types, many fields are only relevant to a subset of products. This can make managing products in any administrative tool cumbersome for business users, as there isn't always a clear distinction as to what fields are relevant to each product, often forcing the user to scroll endlessly or flip between tabs to fill in what is needed. Increases in the need for training as new users are added to the system can also arise.
With the release of version 1.8.4-GA, we are introducing a new feature we're referring to as Product Types. These allow an admin user to define various types of products and configure the fields that are relevant to them. This includes the ability to toggle the visibility of fields, set default values, add custom validation, and mark whether fields are required. This interaction happens through the Broadleaf Admin Interface and requires zero code configuration. In addition to managing existing out-of-box or domain extension fields, users can add net-new custom fields to the form. The data for these fields is stored in the product's attribute map and is accessible to both the front-end storefronts as well as in the backend service code.
Creating a new Product Type
Let’s walk through an example of creating a new Product Type. Once logged into the Admin, you’ll see a new “Product Types” section under the “Catalog” grouping of the main navigation. This is where we’ll manage all of our new Product Types. Out-of-box, no product types are defined so that the list will be empty. We’ll start by clicking the “Add Product Type” button in the top left of the view. This takes us to the create screen, where we can give our new type a name and description.
Here you can see I’ve called our new type “Device” and given it a short description. The “Product Type Key” was automatically generated for me based on the name field and is stored on the product record to denote its type. One remaining field to fill out is the “Base Product Type.” This currently lists the out-of-box Broadleaf product merchandising types. I need to let the system know how to manage the product while processing through the customer’s purchasing flow. In the case of devices, I want to select variant based, as we would like to sell different variations of a single device (i.e., 64GB vs 128GB).
After clicking the create button, I’m presented with two new options: the ability to modify the create and update forms for this type.
Within the Broadleaf Admin, we split out the create flow from the update flow as, typically, there are specific required fields necessary to create a product. It makes the form much shorter and, therefore, easier to comprehend what is needed. Let’s modify the create form to understand how product type maintenance works.
Here, we’re presented with a form that looks very similar to a variant-based product's actual product maintenance screens. We can see what fields are visible, which are required, and any default values.
Hovering over one of these, we get two options. The first is a quick way to toggle the visibility of the field, while the second will give me additional options to configure. Here, I’ve set the “What type of product is this?” to be hidden.
Next, let’s look at the “Is this item active?” options; I’d like these products not to be active by default.
Because this is a Yes/No field type, the admin gives me a simple toggle when setting the default value. I can also change the label and configure several other field properties. For now, we’ll put the default value to “No” and click save.
We can see our change in the screenshot above. Device-type products will now not be active by default. I’ll click the “Save Changes” button in the top right to confirm my changes. Before we look at what it’s like to create a device-typed product, let’s modify the update form, as there are a couple more things to look at.
The update form has several more fields than the create form, including several grids such as “Variations.” If I scroll down to the “Product Options” section and hover over the variations grid, you’ll see a drop-down allowing us to change the various forms that come with the grid.
Selecting the “Create Variant Form,” we’re presented with a pop-up showing all the available fields when creating a variant from the product screen. This is extremely useful as clients rarely use many fields in the variant forms, and being able to default and hide them will surely streamline the process of creating and updating variants.
Modifying these nested forms works precisely the same as in the top-level forms, allowing us to customize the product maintenance user experience fully. Let’s move on to creating a new device typed product.
Creating a new Product
To create a new product, I’ll navigate to the “Products” section of the admin by clicking the link in the main navigation. If you’ve used Broadleaf in the past, you’ll notice a slight change to how this screen is presented. All products, regardless of type, are now shown in a single table that can filter to a specific product type. There’s also the ability to search by name and use advanced filtering.
Let’s add a new product by clicking the “Add Product” button in the top right corner of the screen.
We’re presented with a popup asking us what type of product we would like to create. You’ll notice our new product type as well as the out-of-box Broadleaf types are on the list. It’s important to note that by enabling Product Types, you don’t lose the ability to manage your products as you have in the past. This is meant to enhance your work with products but doesn’t require using the feature.
After I select “Device” and click Create, we’ll be taken to the Device creation screen that we were just modifying. The screenshot below shows that the “What kind of product is this?” has been hidden from the form, and the product is not active by default.
At this point, we could fill out the form and click the create button, and we would have a brand new product with the type of “device.” Instead, I want to talk about another feature of Product Types that I somewhat glossed over before.
While having a product type of device is excellent, many different devices exist. We could have phones and tablets in a telco store, for example. There could be a lot of overlap between these two types of devices when it comes to configuration, and it would be nice to reuse a lot of the work we’ve already done to configure our type. There are a couple of ways to accomplish this reuse, and we’ll talk about two of them.
Custom Fields
The first way we could handle this use case would be to add a new field to our device products to let the user choose the kind of device they want to manage. To do this, we’ll return to our Device type maintenance screen and modify the create form. In the top right corner of the “Basic Information” group, there is a button that will allow us to add a new field.
This brings up a form that lets us define our new field.
In this case, I’ve made this an Enumeration type field and provided the allowed values. I could have simply made this a string field and allowed the user to input the device type manually, but having set options reduces mistakes.
After clicking the submit button, we’ll see our new field in the form and a unique indicator that this is a custom field. As when modifying an existing field, I’ll need to click the save changes button to make this custom field. I’ll go ahead and do that and head back to the device creation screen to see the results.
Back at the device creation screen, our new custom field is visible and will let us choose between creating a phone and a tablet. This additional field, combined with our product type, gives us much flexibility regarding purchase flows from the consumer-facing storefront. It also gives our engineers additional fields to use when performing backend logic. And this was accomplished without needing one of those engineers to write a single line of code!
When creating our devices, this is already a good user experience, but we can take it further.
Product Type Inheritance
When we created our device product type, we had to specify its base product type. At the time, only the out-of-box merchandising types were present. Now that we have a different kind in the system, the next product type we create can inherit from our existing one.
Let’s look at how it works by creating a new “Phone” product type.
Here you can see that I’m setting up our “Phone” product type and specifying that its base type is our newly created “Device” product type. Looking at the create form for this new phone type, we’ll see all the previous changes we made on the device type. Now we can hide fields that may not apply to phones and provide default values where necessary. One such default value we could set is our “device type” custom field. I’ll make the default value “phone” and mark the field as read-only.
At this point, I’ll save the changes, head back to the products screen, and create a new product of type “Phone.”
As you can see, our custom field now defaults to “Phone” and is read-only. We could have made the field hidden instead of read-only, eliminating any confusion as to why it’s present in the form and achieving the same result.
This was a relatively simple example, but it shows how powerful these new Product Types can be when managing and merchandising your products.
TLDR;
Product types allow administrators to effortlessly define, customize, and oversee distinct product types with tailored attributes. This results in streamlining processes, reducing training efforts, and simplifying the handling of diverse product ranges. Businesses can utilize this to become more organized, efficient, and customer-centric around product management. The seamless integration of frontend and backend functionalities ensures a simple and cohesive experience for users and customers.
