• Log in
  • Contact Us

Get in touch  

Blog • Developer

March AMA. Setting up variations in Moltin dashboard

Last updated: 21 Jun 2019
View the video or read a complete transcript from the live session with Matthew Foyle, Customer Success, who walked us through how to create and manage variations with Moltin.

Hey, folks. Today we are going to do a very brief, but hopefully comprehensive run through of the variation system in Moltin. We'll start by looking at the overall process, when you might use it and how you might use it, and we'll actually run through that process using the dashboard without any code.

Once all of your products have been set up and the variations being set up, you'll have some child products generated, and we'll explain the difference between base and child in a moment. Once you have those child products generated, you can then use them in your application, and we will look at a code implementation of how that can be used. We'll then finish by just looking at some of the documentation and some of the resources you can use, maybe some of the common questions, and then we'll leave you to it. So, let's jump in.

When would you use variations? Say you have a product or a number of products that have many attributes that are the same, and some attributes that are different enough to make them different products. The t-shirt is the classic example. Every t-shirt has the same shape, generally in the manufacturing line it's going to have a lot of common attributes with some very significant variations like, size and color. So you want to represent those in Moltin, and you're not going to want to have to create a brand new product, brand new t-shirt for each possible combination of variations that you have.

Remember, if variations are size and color, one of those combinations might be small green or extra large red, and quite often as your catalog grows you're going to have to add new variations, new options, and new products very, very often. So managing that entirety yourself without a system to do so would be just completely unwieldy. Variations give you a way to manage that system and allow you to configure the options and the variations, so that you can use one product, i.e. a base product to build all of the child products. A child product is a combination of the options, so a child product would be our small green or extra large red t-shirt.

Depending on the number of variations and options you have, a different number of child products will be generated, because one will get generated for each possible combination of your options. Let's say you had size and color here, and then you added style and you just had seasons for that: autumn, winter, spring, summer. You would then have different options generated for each combination of size and color, but also factoring in season, so for every small red t-shirt that you have there will now be a small red summer, small red winter, small red spring, etc. Managing this using a system like variations is really powerful, because it allows you to evolve it as you go, and just rebuild your child products as you go without having to delete those and look at how you want to generate them again yourself.

We know it's important and we know that Moltin has a system to do so. We don't yet know how exactly this works, and we'll run through it here. What you can see in my screen is just a brief diagram showing the process of actually getting from one base product. That's the thing, just representing the common attributes to all of your child products, i.e. those products representing every possible combination of the options along the way.

First, obviously, you do need the base products. Again, I would use something like t-shirts in this example. Let's let's hop across and do it here [in the dashboard]. We need a base product. We've said that the base product is just going to be the common attribute, so in this case we could just call it t-shirt. Now, I'm going to do something here because I know what's going to happen in a few minutes but I'm not going to explain it yet so don't worry.

We will come back to slugs in a second, because I imagine it can be confusing if you don't know how it's going to be used. About price, again, you're not going to be selling it. You just need a price in this case, these products need a price. It is something that we can manipulate throughout the process of generating the child products. So we'll see that in a second.

We've got a base product. Amazing. So if you go back to our diagram we say we need variations, so variations look like, as you can see here, they're kind of buckets of things that are going to change, the attributes that aren't going to be common to the base product. So, size is going to change, color is going to change. Let's do that. Variations, new. Let's go: size. Let's go: color. Excellent.

This didn't actually do anything, as you can see. We just created two buckets of things called size and color, but we know that they're related to our base products because it's in this tab here. I'll mention at this point this is the way the dashboard is set up, because it's often convenient to immediately relate variations to your base product. If you're using the API, you don't necessarily have to do it this way. You can generate variations on their own, and attach them, as the dashboard is doing here, but to multiple products. For example, you could not just have t-shirts that do size and color, you could have jeans, etc. So you can reuse the same variation, which is not the case with the dashboard. But you can do so through the API.

All right. What's up next? We've got some options. Buckets are getting smaller, so we're actually getting to the things that will change. We're now specifying small/medium/large and red/green/blue. In this case, we'll make it a little simpler. Each variation mentioned should have an option. The options for size. Again, we set small. That's the S. Medium. Let's just leave it at that for a moment. We'll do a color, a couple of options for color, red and green. Excellent. We can see this tree is emerging now.

Modifiers, here's where the magic actually happens. So far, we've just created a specification essentially to say: These are the buckets of things that will be different per child product, and these are the actual options for those differences; but we haven't actually specified how to change those child products based on these three things. For example, if we just said, "Generate our child products," well, all of the child products would look exactly like this because I'll always specify these variations and options. We haven't actually said how they should change this base product.

Our modifiers modify the base product. Let's add a couple in. For every option you will always need a slug and a SKU modifier. That's because, remember, we said if we generated them now, all the child products would look like this. That would mean there are unique products in the system. Moltin won't allow that for fairly obvious reasons, so we identify uniqueness based on the slug and the SKU. Therefore, we need to modify the slug and the SKU. Now, there are various other modifiers available and, in fact, there is a couple of ways to modify the slug and the SKU. Let's have a look at them, and this will explain what I was doing earlier when naming the product.

I have some modifiers. Excellent. We've got quite a few. So you can imagine what these are doing. Incrementing the price, decrementing it, equaling it. Okay. This looks like it could be useful. We've got sku_builder and slug_builder, but we also have slug_append, sku_equals, slug_equals, sku_prepend.

What we're going to take from this is that you can modify the SKU and the slug. You can either add something to the end of it, to the beginning of it, or equal it, or you can do a builder. Now, this doesn't quite make much sense on its own, so we will run through the process quickly and we'll make the blog post available which describes how this works afterwards so you can read it in your own time.

A builder is going to use something called seek set. In this case, if it's a slug builder ... let's go through it here. Size small, we want a modifier. SKU builder first, and we have our seek set, so we can presume from this it's going to look for something in the SKU and it’s going to set something else in place of it. Now, when you saw me do size earlier in the SKU that makes a little more sense. I think in this case we had small, say, let's do it for the slug as well, and I'll do it for this as well. Size: medium. Finally, a slug.

So, if we want to and build our child products we now have something to actually modify the slug and the SKU for size. We don't for color, but let's get to that in a second. However, if seeking size, there's nothing that says size here. I happen to know already that the syntax for adding a seek set modifier looks like curly braces, so we should add it in here. Tell you what, let's do our color while we're at it.

Size, color options. Pop that in the slug, and pop that in the SKU. Sew it up. Looks good. Okay. Tell you what, why don't we try and build this, see what happens? So you've got to color and color is one of the options, and it knows that every option needs a slug and a SKU modifier. Bear with me here. Go as fast as I can. Okay, voila! As you can imagine, if you were using the API you could script all of this. So you can do it multiple times just using a piece of code, which I highly recommend instead of adding them each time in the dashboard.

So now it looks like we've got two size, one color. Medium, small, and the only color was red, so we got both [t-shirts] being red. If we had had green here then would have had double the amount. All right. So we've got our child products. Now what the hell did we do with these? Well, first of all, they're actual products. They look like any other one. They look like this t-shirt. So if you go back to the catalog you see them. Let's take a look.

We didn't add any price modifiers, so this price will look the same as the base product. It's inherited. Stock, as we can see, is not inherited. That's because you're going to have different stock units for a small red t-shirt as opposed to another one, like any business. We can then go update the stock. Okay, great. 10 for a small red. You would do the same for things like images or anything that is going to be completely different for each child because you can't really configure that based on the base product.

Now that we have them, we need to look at how they would be used. Well, in fact, there's a nice little setting in the API that says, "Do you even want to show your child products?" The reason for that is the child product is the thing you will be adding to the cart, but you don't actually need to use it on the product listing page. All you need is your base product and the options. The reason for that is because your base product knows what options it has, what variations it has, and indeed what child product IDs it has for each one. That's called a variation matrix. What we normally see are consumers of the API turning on this setting, making sure the child products aren't shown in the API response, and then they look at the base product. So we've got a bit of code coming here, but nothing serious.

This is what it's actually doing. It's getting the base product and saying, "Oh, great. We know what our options are. We can let the user choose." Medium, red. This is using a different product, as you can see. This is in fact the idea of the child product. You can add that to cart, and off you go. So all you need is the base product and I'll show you exactly how this works now.

This is part of the API response for the base product. You'll see this thing we talked about called variation matrix. This essentially just goes down layer by layer through all of the different options to get you to the IDs for each possible combination. In this case, this is the ID for the small option for size, it's the ID for the red option for color. So within this block we've now got everything that is small and red. There are only three variations here, size, color, and the style. So we're now at the last layer, last piece of the puzzle.

There are three options for something that's small and red, it can be noon style, dusk, or moon. Soon as I choose I know which child product at the end. We then go back up a layer. So we're still at small, but we're now at white. So for small light there are three options again: noon, dusk, and moon. Again, we can choose whatever we want based on the choices provided to us by the user, and off we go. Using this you can very quickly get to the product that you need based on the options the user chooses. I'll hop back here and just point out that at anytime we can go in, we can add new modifiers, new options, and we can rebuild our child products.

So super simple and super easy to evolve this process. It is worth mentioning though, if you're relying on product IDs, these may change. The reason they may change is let's say we added a new variation in here called style. We added, say, the three options, moon, dusk, and noon and a slug and a SKU modifier for each. We build our child products, well, now there's no small red t-shirt anymore. There's a small red dust t-shirt, a small red noon, but a small red t-shirt doesn't exist anymore, and so its product ID doesn't exist anymore. In those circumstances you're essentially creating brand new products and tearing down the old ones. So when you rebuild internally it looks at the Hash of these options and the combinations previously, and if new products are going to be generated, like entirely new products, I believe that the child IDs will be different. Something to bear in mind.

Last couple of things on this. Let's think about your inheritance. Think about what properties are inherited from the base product. And remember stock is not one of those things. Obviously anything you can put modifiers on can be inherited. Think about whether your base product is live or draft, think about whether your child products are live or draft, and think about the setting in the API that says, "Do you even want to show those?"

When you've got your child products think about how many of these are actually being generated. You'll see in this case two variations, one option, two options, three options. Overall, we only have two child products, but as you can imagine this grows quite significantly as soon as we add another two variations, another two options. Now the limit in the API I believe is 200, so you're going to want to configure your system in order to not have 200 or more per base product. You want to have multiple base products. Remember, you can attach the same variations to multiple base products, so this should make it a little easier on you.

All right. That's pretty much the gist of it. You have documentation for all of this. It's in docs.moltin.com. There is even developers.moltin.com, a nice little example for variations here. It outlines this last little diagram here showing you how the options and combinations get generated together, and how it's represented in the variations matrix, shows you how to reuse things, shows you the set up; as we just did there; and a lot more code, and shows you how to use them.

I'm going to leave it there, but I will mention one last thing. People often wonder how this works using Flows, and there are two aspects to it. Because the child products are just products they do have custom data coming with them. So if you have a Flow ... Again, Flow is just some custom schema. If you have a Flow for your products and that has an extra field called, you know, whatever, promotion; for example, or customer group is another example, then all of your child products will inherit that property. It won't have a value yet because you haven't specified it. But again, you can script that using some code. So once again, base products and child products are just products. The difference being that you're adding the child product to cart, not the parent.

All right. I'll leave it there for now. We do have some questions, but I think to make best use of everyone's time here I'm going to write those up afterwards and properly consider the answers, so this time leave you guys do it. Thanks again.

Explore More Blog Posts

24 Oct 2019

November - product updates & deprecations

On Thursday 12th December we will be fixing an issue which results in flow data for orders appearing on the orders transactions.

Read More
Adam Sturrock
in Developer
30 Sep 2019

Onboarding with Moltin

The aim of this post is to give you a view into how onboarding works at Moltin. It is designed around a service based implementation.

Read More
Matt Foyle
in Magento Migration | Developer | eCommerce
11 Sep 2019

eCommerce API 101

In this post we’ll cover what an eCommerce API is, why you should use one and how you should evaluate an eCommerce API.

Read More
Adam Sturrock
in Developer | eCommerce