--- title: Content Models slug: oms/content-models docTags: createdAt: 2022-07-27T19:30:16.000Z --- # Overview Our **Autonomy** starters use existing content models that have been provisioned by the team at Chord Commerce when we bootstrapped your CMS environment. You can use the (simplified) diagram below to learn more about how core models are interconnected: ![](https://api.archbee.com/api/optimize/TmutqdeXiIw-V3gBZXVjd/BYHirg5f119WZtFn0kxBi_autonomy-content-models-simplified-1.jpg "Chord CMS Content Models") ## E-commerce Content Models When starting with Chord Autonomy, your initial CMS space will come with more CMS types than what are listed here. You are free to remove/edit content types that are not listed here. **The content types listed here are all required for Chord's OMS and its sync service to function properly**. With that said, you are free to add whatever fields you would like to the following content types, so long as they do not clash with the fields explicitly listed. ### Common Required Fields Most of Chord's content types have a set of required fields across them that are required for Chord to properly function. These fields are frequently used so that our sync service can sync changes between the CMS and the OMS. **You should not remove these fields from content types as it will break syncing from the CMS to OMS**. ### Name The name for an item that may or may not be displayed to your customers in the storefront's UI in Chord's Autonomy starters. We note cases where the name is displayed to customers in specific content types in this document. It will be shown in the CMS as the title for a given entry and it may be synced to Chord's OMS, in the case of content types like [Content Models](docId\:gojr-A1zivmF6EYSr-M4c) and [Content Models](./#variant). Generally, the name for an item should make sense from an operational standpoint and not a marketing standpoint. It is a required field and should not be removed from a content type if it's provided to you as a part of your initial CMS space. Some examples of the name format are: - `The Plant Store` - `Colorado Blue Spruce` - `Poplar Tree` It is recommended that you add a name field to all custom content types that you end up creating, even if you do not display the name to a customer. ### Slug The slug field is a [slugified](https://en.wikipedia.org/wiki/Clean_URL#Slug) string that is unique to that content type and is the human readable identifier for a given item. This field can be used in URLs to route to the item. Some examples of the slug format are: - `the-plant-store` - `colorado-blue-spruce` - `poplar-tree` If this field is present in a content type provided to you in our initial CMS space, **you should not remove it from the content type**, as that will break elements of our sync service from the CMS to the OMS. It is recommended that you add a slug field (or something like it) to each custom content type that you end up creating in the CMS, even if you don't plan to route to it initially. Having a unique, stable, human readable identifier can be very helpful when querying for a single record. :::hint{type="danger"} **We do not recommend changing the slug after it has been set. This can lead to some syncing issues with the OMS for content types. ** ::: Changing the slug after it has been set can lead to some syncing issues with the OMS for content types. When changing it for types like [Content Models](./#product) or [Content Models](docId\:gojr-A1zivmF6EYSr-M4c), you should check the OMS afterwards to see if duplicate items were created. ### Use Case To illustrate the content models used by Chord Autonomy, we are going to imagine a store that sells a variety of plants called "The Plant Store". :::BlockQuote The Plant Store is an established business that sells houseplants, shrubs, flowers, trees, and plant supplies, like soil and plant food. The Plant Store currently has a single storefront located at `https://theplantstore.com`. ::: ## Catalog The **catalog** is the top level taxonomy for the items in a store. For Chord customers with a single storefront, you will frequently have one catalog that you use for your whole site. Chord customers with multiple storefronts should have multiple catalogs in their CMS, one for each storefront. ### Required Fields | Field Name | Field Description | | ----------- | ---------------------------------------------------------------------------------------------------- | | | The name for an item that may be displayed to your customers\*\*.\*\* | | | A string that is unique to that content type and is the human readable identifier for a given item. | | Collections | A many-to-many reference of in this catalog. | ### Use Cases To illustrate some of the finer points of the **catalog** content type, let's consider what we would do if The Plant Store wanted a single storefront at `theplantstore.com` versus multiple storefronts corresponding to their verticals (ex: `theplantstore.com`, `theshrubbery.com`, `flowers4u.co`, etc.) ### Single Storefront :::BlockQuote The Plant Store is coming to Chord with an existing site where all their products are listed and they would like to keep it that way. ::: If The Plant Store wanted a single storefront, they would create multiple [Content Models](./#collection) corresponding to their verticals (`Houseplants`, `Shrubs`, `Flowers`, etc.) and associate them with the singular catalog record with the `slug` of `catalog`. ### Multiple Storefronts :::BlockQuote The Plant Store would like to diversify itself into multiple storefronts corresponding to its verticals (all flowers on `flowers4u.co`, all shrubs on `theshrubbery.com`, and all houseplants on `theplantstore.com`). ::: If The Plant Store wanted multiple storefronts, they would create a **catalog** entry for each site (`Flowers 4 U`, `The Shrubbery` and `The Plant Store`) and then either: - Create a single [Content Models](./#collection) for all products in the store (ex: `flowers4u.co` has all flowers in a single collection) - Create multiple [collections](#) that highlight distinctions in groupings of items (ex: `flowers4u.co` has the following collections: `Tulips`, `Roses`, `Orchids`, and `Accessories`) ## Collection A **collection** is a grouping of items for sale in a storefront. In the Autonomy default content model, a collection is a grouping of [products](#) and [kits](#). It should be noted that products and kits can exist in multiple collections. ### Required Fields **All of these fields are required for Chord's OMS and its sync service. Do not remove them from the collection content type.** | Field Name | Field Description | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------- | | | The name of the **collection**. By default, in our starters, this is not shown to the customer and is used as an internal identifier. | | | The identifier of the **collection**. | | Products | A many-to-many reference to the content type that represents all the products in this **collection**. | | Kits | A many-to-many reference to the content type that represents the kits in this **collection**. | ### Use Case :::BlockQuote The Plant Store sells many plant accessories, such as soil, pots, vases, plant food, and everything in between. They would like to have all these accessories in an "Accessories" collection on the site, and they would also like some of their vases to show up with their flowers. ::: In order for The Plant Store to do this, they would: 1. Create their "Accessories" **collection** along with their other plant-focused **collections**, like "Flowers." 2. Add all their accessory [products](#) to the "Accessories" **collection**. 3. Add some of the vases to the "Flowers" **collection**. ## Product A **product** is an item for sale in a storefront. It contains information about the product, like the name, description, ingredients, and other metadata. All product management lives in the CMS and is synced to Chord's OMS via our sync service. An important fact to know is that the product content type itself does not have information like the price, [SKU](https://en.wikipedia.org/wiki/Stock_keeping_unit), weight, and other pricing/shipping information, nor should it contain this information. This information will be set in one or more of the product's [variants](#). ### Required Fields **All of these fields are used by the Chord OMS sync service and should not be removed from the product content type.** | Field Name | Field Description | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name of the **product**. In our starters, by default, this name is shown to customers, both in the store's UI and in the `` tag of the document. | | | The identifier of the **product**. In our starters, by default, this is used in the path portion of the URL to route to the product display page. | | Main Image | The primary image to be shown for this **product**. It is used not only on your website, but also in the Google Search results for this product (through the ) and other metadata about this product. It is also synced to the Chord OMS through our sync service and will show up in that UI. | | Option Types | are modifiers for a product. If you were to sell a t-shirt, the size of the shirt for sale would an **option type** and the sizes (small, medium, large) would be [option values](#). | | Variants | A **product** is required to have at least one which represents a SKU, which is an item type in your warehouse. There must be a variant for each combination of the product's [option values](#). The variant contains data for the **product** for pricing, shipping, discounts, and more. | | Subscription | The subscription field allows this product to be purchased by customer on a recurring basis by adding a reference to an instance of the content type. | ### Use Cases To help illustrate some of the finer points of the **product** content type, consider the following use case: :::BlockQuote The Plant Store sells red, yellow and purple tulips. The customer can purchase these tulips in a size of small (5 tulips), medium (10 tulips), or large (30 tulips). ::: In this use case, we are going to model The Plant Store's content to work with Chord's Autonomy starters, which have product display pages with select menus for all possible [variants](#) for the product. There is nothing stopping you from having **variant** display pages where customers can buy specific variants. There are two ways that The Plant Store could model their products and variants: ### All Tulips On A Single Page In this use case, The Plant Store would like all tulips for sale on a page with the URL of `https://theplantstore.com/products/tulips`. In order to do this with Chord's Autonomy starters, they do the following: 1. Create a **product** named "Tulips". 2. Create the [option types](#) for the "Size" and "Color". 3. Create the [option values](#) for the "Size" option type ("Small, "Medium", "Large") and "Color" option type ("Red", "Yellow", "Purple"). 4. Add a [variant](#) for each combination of of the option types/values with names like "Red Small Tulips", "Purple Medium Tulips", "Yellow Large Tulips" and so on (there will be 9 variants attached to the "Tulips" product). The biggest advantage to this approach is that you get a single logical **product** to manage all the SKUs in the CMS. ### Each Color Of Tulip Has Its Own Page In this use case, The Plant Store would like for each color of tulip to have its own page. To do this, they would: 1. Create a **product** for "Red Tulips", "Yellow Tulips" and "Purple Tulips". 2. On each **product**, they add an [option type](#) for the size of the order and create three variants on each tulip product corresponding to the size (`small`, `medium` and `large`). The advantages of this solution include: - Better search engine optimization, in the default product display page setup in our starters, as it's more likely to catch specific queries like "red tulips" with this approach. - Easier top level product management in the CMS, as the individual colors are easier to view at a product level than they are at a [variant](#) level. ## Kit The **kit** content type represents a grouping of [products](#) that can be sold at a set price. A kit is great when you would like to bundle [products](#) for sale together at a discount. It should be noted that, from a Chord OMS perspective, that a **kit** generates a distinct [SKU](https://en.wikipedia.org/wiki/Stock_keeping_unit) in the OMS. This product in the OMS will have variants for every possible combination of the included product's variants. The [SKU](https://en.wikipedia.org/wiki/Stock_keeping_unit) will be an alphabetized pipe joined list of the [variants](#) in the SKU which looks like the following: ```Text variant-sku-1|variant-sku-2|variant-sku-3 ``` ### Required Fields | Field Name | Field Description | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name of this **kit**. This name is synced to the Chord OMS and is displayed to your customer by default in the Autonomy staters. | | | The slugified identifier for this **kit**. By default, in the Autonomy starters, this fields is used in the path portion of the URL for the kit display page. It is also used by the OMS sync service to sync the **kit** to the OMS. | | Products | The to be bundled together in this kit. | | Price | The amount of money to charge the customer for buying all these items together in this **kit**. | | Regular Price | If you would like to emphasize that buying these products together in a **kit** would save the customer money, you can enter the regular price here. If it is not on sale, set it to what the price is. | ### Use Case :::BlockQuote The Plant Store would like to sell red roses with a glass vase and a box of chocolates for Valentines Day for $100 with a name of "Nothing Too Sweet For My Honey". ::: In order for The Plant Store to offer such a bundle, they would: 1. Create a **kit** with the name of "Nothing Too Sweet For My Honey" and set the price to $100. 2. Add the [products](#) (red roses, glass vase, box of chocolates) to the **kit** created in step 1. 3. When the kit is synced to the Chord OMS, there will be a new SKU with the identifier `chocolates|glass-vase|red-roses`. ## Variant The **variant** content type corresponds to a type of item in your warehouse and contains all the pricing, discounting, shipping, and warehouse metadata for a [product](#). All **products** must have one **variant** per combination of [option types](#) attached to it. If there are no **option types** on the **product**, the **product** must still have one **variant** record that represents its only variation. To reuse an analogy from the [product](#) section, if you are selling a "t-shirt with the Chord logo," a **variant** of it would be a "medium t-shirt with the Chord logo." If your customer is on a [product](#) page, they can be presented multiple variants of that product. The customer is able to select that variant by making selections of that product's [option types](#) which will map to [option values](#) placed upon the variant. If you were selling a "medium t-shirt with the Chord logo," you would: 1. Create a [product](#) named "Chord T-Shirt" 2. Add a **variants** to that [product](#) named "Small Medium Chord T-Shirt," "Medium Chord T-Shirt," and "Large Chord T-Shirt" 3. Add an [option type](#) named "T-Shirt Size" to the "Chord T-Shirt" product 4. Add [option values](#) to the "T-Shirt Size" option type named "Small," "Medium," and "Large" 5. Add the [option values](#) to the variants ("Medium" [option type](#) to "Medium Chord T-Shirt" **variant**, repeat for the "Small" and "Large" option types) The starters provided by Chord have product pages and checkouts already set up to work perfectly with this product/variant/option type/option value setup. ### Required Fields **All fields listed here are required and should not be removed from the variant content type.** | Field Name | Field Description | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | The name of the **variant**. In the Autonomy starters, this name is displayed to the customer when the variant of a product is selected. | | Price | The price of this variant of the in the currency defined in the Chord OMS for this storefront. If you are thinking about setting up your storefront for multiple currencies, reach out to the Chord team for further discussions. | | Regular Price | If the product is on sale (or you want it to appear as if it's on sale), this is where you would set the regular price of the **variant**. If it is not on sale, this field should equal the value in the **price** field. | | Weight & Total Packaging Weight | This is the weight of the product variant without packaging and with packaging. These fields can be used to calculate how much shipping might be for some shipping services in the Chord OMS. | | SKU | The internal identifier for this product variant. It is used by Chord's OMS sync service to sync pricing and shipping information to the OMS, so the SKU shouldn't change and should be considered stable. This field can functionally serve the same purpose as the on other content types. | | Global Trade Item Number | The /barcode for this product variant. | | Option Values | A many-to-many reference to the content type. It is used to match the variant to what the user wants to purchase on a [product](#) page. | ### Use Case :::BlockQuote The Plant Store sells sunflowers. They sell them in bunches of 6 (small, $20), 12 (medium, $40), and 20 (large, $65). Sunflowers are in season right now and they have a surplus of them in stock and have to move them quickly. To do so, they are going to offer a discounted price when customers purchase larger sizes, discounting a medium order of sunflowers to $30 and a large order to $50. ::: In order for The Plant Store to offer sunflowers in such a fashion, they would: 1. Create a [product](#) named "Sunflowers." 2. Create an [option type](#) named "Size." 3. Create [option values](#) that reference the [option type](#) "Size," named "Small", "Medium," and "Large." 4. Create **variants** for the [product](#) "Sunflowers" named "Small Sunflowers," "Medium Sunflowers," and "Large Sunflowers." 5. Set the [option values](#) on the variants to match their size through the "Size" [option type](#)**.** 6. Set the prices and regular prices on the **variants** to match the one described in the use case. ## Option Type The **option type** content type represents an option for the customer to pick when adding a product to their cart. Imagine the option type as a dropdown in a form and the values in the dropdown would be [option values](#). If you were selling t-shirts, the size of the shirt would be an **option type** with [option values](#) for "small," "medium," and "large." Option types are part of the glue that binds a [product](#) to a [variant](#). To make an analogy to HTML (and how it might show up in the Chord UI), the **option type** is a `<select>` element and the **option value** is the `<option>` element for that `<select>`. It is encouraged that you reuse **option types** (where it makes sense) across your [products](#). ### Required Fields **All of these fields are required for Chord OMS and its sync service to work properly. Do not remove them from the option type content type.** | Field Name | Field Description | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name of the **option type**. This is primarily used as an internal identifier in the CMS interface to describe the **option type** and is not displayed to customers in the Chord Autonomy starters by default. | | | The identifier of this **option type**. To continue the HTML `<select>` analogy from above, this field maps to the `name` attribute on the `<select>` element. | | Option Values | A many-to-many reference to the content type. | | Presentation | The human readable description of this **option type**. To continue the HTML `<select>` element analogy from above, this would be the `<label>` for the `<select>`. | ### Use Case For a detailed use case of how to use **option types**, please refer to the [variant's use case](#). ## Option Value The **option value** content type represents an option for an [option type](#). If you were selling t-shirts, the size of the shirt would be an [option type](#) and "medium" or "large" would be an **option value**. Option values are part of the glue that binds a [product](#) to a [variant](#) through [option types](#). To make an analogy to HTML (and how it might show up in the Chord UI), the **option value** is an `<option>` element to a `<select>` represented by the [option type](#) content type. ### Required Fields **All of these fields are required for Chord OMS and its sync service to work properly. Do not remove them from the option value content type.** | Field Name | Field Description | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name of the **option value**. This is primarily used as an internal identifier in the CMS interface to describe the **option value** and is not displayed to customers in the Chord Autonomy starters by default. | | | The identifier for this **option value**. To continue the HTML analogy from above, this would be the `value` attribute for the `<option>` element. | | Presentation | The human readable description of this option value. To continue the HTML analogy from above, this would be the text inside of an `<option>` tag. | ### Use Case For a detailed use case of how to use **option values**, please refer to the [variant's use case](#). ## Subscription The **subscription** content type allows you to define recurring purchases of [products](#) or [kits](#) for your customers at a custom interval defined by the [subscription interval](#) content type. Chord Autonomy's subscription model allows you to give your customer a discount on their recurring order based upon a percentage discount. A single subscription can be associated with multiple products by adding an instance of the **subscription** to the desired products. Chord's OMS handles all of the recurring billing and order management around subscription orders. ### Required Fields **These fields are required by the Chord OMS sync service and should not be removed from the subscription content type.** | Field Name | Field Description | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name for this **subscription** type. In the Chord Autonomy starters, this name is not displayed to the customer. It is used by Chord's OMS sync service and should serve as an internal name for this **subscription** type. | | | The internal identifier for this **subscription** type. This is used in Chord's OMS sync service to sync subscription to the OMS. It is also used in Chord's Autonomy starters in the subscription selection dropdown. | | Discount Percentage | The percent of money to take off of the subscription product's price. Set it to 0 if the subscription should not be discounted. | | Intervals | A many-to-many reference of the content type, defining the acceptable intervals for the subscription to reoccur for the customer. | ### Use Case :::BlockQuote The Plant Store offers their customers the ability to send roses or violets to a loved one on a weekly and monthly basis at a 10% discount. They want to promote it with the name of "'Always Thinking About You' Subscription." ::: In order for the The Plant Store to offer such a subscription, assuming they had already created the roses and violets [products](#), they would: 1. Create a new **subscription** named "Always Thinking About You" with a 10% discount. 2. Add new [subscription intervals](#) set to repeat every 1 week and every 1 month to the subscription. 3. Add the **subscription** to the "Roses" and "Violets" [products](#)**.** ## Subscription Interval The **subscription interval** content type represents a reusable unit to define how often a subscription purchase should reoccur. ### Required Fields **These fields are required for the Chord OMS sync service to work properly so do not remove them from the subscription interval content type.** | Field Name | Field Description | | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The name of this **subscription interval**. In Chord's Autonomy starters, by default, this field is shown to your customer in the subscription selection dropdown. | | | The identifier for this **subscription interval**. It is used by Chord's OMS sync service to sync **subscription intervals** to the OMS. It is also used in the subscription selection dropdown in Chord's Aut**onomy starters.** | | Presentation | The customer-facing name of this subscription interval. | | Unit | The measurement for the interval. These can be either days, weeks, months, or years. | | Length | The number of the subscription should reoccur upon. | ### Use Case Refer to the [use case for subscriptions](#) for an in-depth description of how **subscription intervals** function.