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:

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.

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.

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 and Content Models. 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:

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.

The slug field is a slugified 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:

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.

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 or Content Models, you should check the OMS afterwards to see if duplicate items were created.

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".

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.

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.)

If The Plant Store wanted a single storefront, they would create multiple Content Models corresponding to their verticals (Houseplants, Shrubs, Flowers, etc.) and associate them with the singular catalog record with the slug of catalog.

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:

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.

All of these fields are required for Chord's OMS and its sync service. Do not remove them from the collection content type.

In order for The Plant Store to do this, they would:

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, 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.

All of these fields are used by the Chord OMS sync service and should not be removed from the product content type.

To help illustrate some of the finer points of the product content type, consider the following use case:

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:

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:

The biggest advantage to this approach is that you get a single logical product to manage all the SKUs in the CMS.

In this use case, The Plant Store would like for each color of tulip to have its own page. To do this, they would:

The advantages of this solution include:

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 in the OMS. This product in the OMS will have variants for every possible combination of the included product's variants. The SKU will be an alphabetized pipe joined list of the variants in the SKU which looks like the following:

In order for The Plant Store to offer such a bundle, they would:

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:

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.

All fields listed here are required and should not be removed from the variant content type.

In order for The Plant Store to offer sunflowers in such a fashion, they would:

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.

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.

For a detailed use case of how to use option types, please refer to the variant's use case.

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.

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.

For a detailed use case of how to use option values, please refer to the variant's use case.

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.

These fields are required by the Chord OMS sync service and should not be removed from the subscription content type.

In order for the The Plant Store to offer such a subscription, assuming they had already created the roses and violets products, they would:

The subscription interval content type represents a reusable unit to define how often a subscription purchase should reoccur.

These fields are required for the Chord OMS sync service to work properly so do not remove them from the subscription interval content type.

Refer to the use case for subscriptions for an in-depth description of how subscription intervals function.