@mercurjs/docs 2.3.8-canary.3 → 2.3.9-canary.1

package/content/platform/attribute/concepts/attribute-types.mdx

@@ -1,59 +1,86 @@
 ---
-title: "Attribute types"
+title: "Attribute types and values"
 sidebarTitle: "Attribute types"
-description: "The five attribute types and the values they hold."
+description: "The five attribute types, how each one stores its values, and the flags every attribute carries."
 ---
 
-In this document, you'll learn about the attribute record, its five types, and
-the values attached to it.
-
-## Product attribute
-
-An attribute is a typed field in the shared catalog, represented by the
-`ProductAttribute` data model (table `product_attribute`, id prefix `pattr`).
-Each attribute carries a `name`, an optional `handle`, a `rank` for ordering, and
-a `type` that decides how its values are validated and rendered.
-
-```ts
-const { result } = await createProductAttributesWorkflow(container).run({
-  input: {
-    attributes: [
-      {
-        name: "Material",
-        type: "single_select",
-        values: [{ name: "Cotton" }, { name: "Wool" }],
-      },
-    ],
-  },
-})
+An attribute is a typed field in the shared catalog, and its type decides what a product can hold for it: a choice from a list, free text, a measurement, or a yes/no flag. Picking the right type matters because it fixes how values are stored and linked, and you can’t change it once the attribute exists.
+
+## The attribute record
+
+Every attribute is a `ProductAttribute` record (id prefix `pattr`) with a `name`, a `type`, and a few flags. Its selectable choices are separate `ProductAttributeValue` records (id prefix `pattrval`) that belong to it and are deleted with it.
+
+```ts title="src/scripts/seed-attributes.ts"
+import type { ExecArgs } from "@medusajs/framework/types"
+import { AttributeType } from "@mercurjs/types"
+import { createProductAttributesWorkflow } from "@mercurjs/core/workflows"
+
+export default async function seedAttributes({ container }: ExecArgs) {
+  await createProductAttributesWorkflow(container).run({
+    input: {
+      attributes: [
+        {
+          name: "Material",
+          type: AttributeType.SINGLE_SELECT,
+          values: [{ name: "Cotton" }, { name: "Linen" }],
+        },
+      ],
+    },
+  })
+}
 ```
 
-The `type` field is one of the `AttributeType` enum values:
+The script creates one global `single_select` attribute with two values. Because no `handle` is passed, the module derives `material` from the name.
 
-| Type | Value | Holds |
-| --- | --- | --- |
-| Single select | `single_select` | One choice from a fixed list of values |
-| Multi select | `multi_select` | Several choices from a fixed list of values |
-| Text | `text` | A free-form string |
-| Unit | `unit` | A numeric measurement (e.g. weight, capacity) |
-| Toggle | `toggle` | A boolean, backed by seeded `true` / `false` values |
+## The five types
+
+The `type` field takes one of the `AttributeType` enum values. Each type stores what a product holds in a different way:
+
+| Type | Enum | A product holds | Where the value comes from |
+| --- | --- | --- | --- |
+| Single select | `single_select` | One choice from a fixed list | Values you create on the attribute |
+| Multi select | `multi_select` | Several choices from a fixed list | Values you create on the attribute |
+| Text | `text` | A free-form string | A new value created when you attach it |
+| Unit | `unit` | A measurement, such as `400` | A new value created when you attach it |
+| Toggle | `toggle` | `true` or `false` | The two values seeded when the attribute is created |
+
+Only a `multi_select` attribute can be a [variant axis](/platform/attribute/concepts/variant-axes). The other four types describe a product but never shape its variants.
+
+## How values link to products
 
-## Product attribute value
+A product doesn’t store attribute data on itself. Instead, each value it holds is linked to it through the product to value pivot link, and the shape of that link depends on the type:
 
-The choices for select-style attributes are `ProductAttributeValue` records
-(table `product_attribute_value`, id prefix `pattrval`). Each value belongs to
-one attribute (`attribute_id`), has its own `name`, `handle`, and `rank`, and is
-deleted along with its parent attribute.
+- **Select types**: the product links to existing values you pick by id
+- **Text and unit**: attaching creates a new `ProductAttributeValue` named after the entered content, for example `"400"`, and links it
+- **Toggle**: the product links to the seeded `"true"` or `"false"` value, and no new value is ever created
 
 <Note>
-  `single_select` and `multi_select` attributes hold a list of predefined
-  `ProductAttributeValue` records. `text` and `unit` create a value on the fly
-  from the entered content when attached to a product. `toggle` is seeded with
-  its `true` / `false` values and never creates new ones.
+  `unit` stores the number as the value’s `name` string. The attribute has no separate unit-of-measure field, so put the unit in the attribute name, for example “Weight (kg)”.
 </Note>
 
-<Tip>
-  Use `is_required` to enforce that a product must carry a value for the
-  attribute, and `is_active` to retire an attribute from new use without deleting
-  its history.
-</Tip>
+## Rules the module enforces
+
+The Product Attribute service adds a few rules on top of the generated CRUD methods:
+
+- **Type is fixed**: `updateProductAttributes` throws when you try to change the `type` of an existing attribute
+- **Handles are derived**: a global attribute without a `handle` gets one from its name, and global select values get one from theirs
+- **Handles are unique**: attribute handles are unique across the catalog, and value handles are unique per attribute
+- **Toggle values are seeded**: creating a `toggle` attribute adds its `true` (rank 0) and `false` (rank 1) values
+
+## Flags on every attribute
+
+Each attribute carries flags that control where it shows up and how it’s treated:
+
+| Field | Default | Effect |
+| --- | --- | --- |
+| `is_required` | `false` | The attachment workflows refuse to remove the attribute from a product |
+| `is_filterable` | `false` | Marks the attribute as a storefront facet |
+| `is_variant_axis` | `false` | Makes a `multi_select` attribute generate a `ProductOption` |
+| `is_active` | `true` | A status flag you can filter attribute lists by |
+| `rank` | `0` | Sort order for attributes and for values within an attribute |
+
+## Related
+
+- [Variant axes and Medusa product options](/platform/attribute/concepts/variant-axes)
+- [Global and inline attributes](/platform/attribute/concepts/global-vs-inline)
+- [Every field on the data models](/platform/attribute/reference/data-models)

package/content/platform/attribute/concepts/global-vs-inline.mdx

@@ -1,50 +1,72 @@
 ---
-title: "Global vs inline & filtering"
+title: "Global and inline attributes"
 sidebarTitle: "Global vs inline"
-description: "Catalog-wide attributes, product-scoped attributes, and storefront filtering."
+description: "Catalog-wide attributes, attributes scoped to one product, category scoping, and storefront filters."
 ---
 
-In this document, you'll learn the difference between global and inline
-attributes and how an attribute becomes a storefront filter.
+Every attribute is either global, a catalog entry any product can reuse, or inline, a one-off field created on a single product. Global attributes keep the catalog consistent across stores. Inline attributes cover the odd field one product needs without adding noise to the shared vocabulary.
 
-## Scope
+## Scope is decided by product_id
 
-Every `ProductAttribute` is either **global** or **inline**, decided by its
-`product_id` field:
+The `product_id` field on `ProductAttribute` decides the scope. It’s `null` for a global attribute and holds the product’s id for an inline one:
 
-| Scope | `product_id` | Meaning |
-| --- | --- | --- |
-| Global | `null` | A catalog entry, reusable across any product, listed in the operator's attribute catalog |
-| Inline | set | A one-off attribute scoped to a single product, created from that product's form and hidden from the global catalog |
+| Scope | `product_id` | Created by | Listed in the catalog |
+| --- | --- | --- | --- |
+| Global | `null` | `createProductAttributesWorkflow` | Yes |
+| Inline | `prod_…` | An inline entry in a product’s `add` list | No |
+
+The admin, vendor, and store attribute list routes all filter on `product_id: null`, so inline attributes never appear in the catalog. You read them from the product through the `scoped_attributes` link instead.
 
 ```ts
-// Global: reusable across the catalog
-{ name: "Material", type: "single_select", values: [{ name: "Cotton" }] }
+const { data: [product] } = await query.graph({
+  entity: "product",
+  fields: ["id", "scoped_attributes.name", "scoped_attributes.values.name"],
+  filters: { id: "prod_01JD8Q1234567" },
+})
+```
+
+## Create an inline attribute
+
+You create an inline attribute while you attach it. An `add` entry with a `title` instead of an `id` creates a product-scoped attribute, its values, and the links in one step:
 
-// Inline: scoped to one product, created as it's attached
-{ title: "Gift wrap", type: "toggle", product_id: "prod_123" }
+```ts
+await createAndLinkProductAttributesToProductWorkflow(container).run({
+  input: {
+    product_id: "prod_01JD8Q1234567",
+    add: [{ title: "Gift wrap", value: true }],
+  },
+})
 ```
 
-A global attribute is defined once and attached to many products. An inline
-attribute is created in the same step it is attached and only ever describes that
-one product. It is useful for the occasional one-off field that doesn't belong in
-the shared vocabulary.
+When you omit `type`, the workflow infers it: `is_variant_axis: true` makes a `multi_select` axis, a boolean `value` makes a `toggle`, and anything else makes a `text` attribute. Inline attributes get no derived handle, so their names never clash with the catalog.
+
+The two scopes behave differently over their life:
+
+- **Rename**: an `update` entry with a `title` renames an inline attribute and, for an axis, its exclusive option, but it’s ignored for a global attribute
+- **Remove**: removing an inline attribute from its product deletes the attribute and its values, while removing a global one drops the product’s value links and, for an axis, detaches the option
+- **Delete**: `deleteProductAttributesWorkflow` refuses to delete a global attribute while any of its values are linked to a product
 
-<Note>
-  Attributes describe products in the **shared master catalog**. They are never
-  owned by a store. A seller sells against a master product through an offer, and
-  the product's attributes come from the catalog, not from the seller.
-</Note>
+## Scope global attributes to categories
 
-## Filtering
+A global attribute can link to product categories through the `categories` link. The admin and vendor attribute lists accept a `product_category_id` filter and return two groups: attributes linked to that category, and attributes linked to no category at all. Category links change where an attribute is offered:
 
-An attribute with `is_filterable` set to `true` is exposed as a storefront
-filter, letting shoppers narrow the catalog by its values. Leave it `false` for
-descriptive-only attributes that shouldn't appear as facets.
+- **No categories**: the attribute is offered for every product
+- **One or more categories**: the attribute is offered only for products in those categories
+
+Pass `category_ids` to `createProductAttributesWorkflow` to create the links with the attribute.
+
+## Storefront filters
+
+Shoppers filter `GET /store/products` with `attributes[<handle>]=value` query parameters. The store middleware turns each one into a filter on `variants.options.value`, so filtering works on variant axis values. Several values for one attribute are OR’d, and separate attributes are AND’d.
+
+`is_filterable` doesn’t change that query. It’s a flag your storefront reads from the store attribute list to decide which attributes to render as facets.
 
 <Tip>
-  Filtering pairs naturally with variant axes: a filterable `multi_select` axis
-  like Color both generates variants and lets shoppers filter by them. A
-  descriptive `text` attribute like Care instructions is usually left
-  non-filterable.
+  Mark axes such as Size and Color as filterable. Descriptive `text` attributes such as care instructions aren’t variant options, so the product filter can’t match them.
 </Tip>
+
+## Related
+
+- [Attach attributes to a product](/platform/attribute/guides/attach-attributes-to-a-product)
+- [Variant axes and Medusa product options](/platform/attribute/concepts/variant-axes)
+- [The scoped_attributes and categories links](/platform/attribute/reference/links)

package/content/platform/attribute/concepts/variant-axes.mdx

@@ -1,20 +1,24 @@
 ---
-title: "Variant axes"
+title: "Variant axes and product options"
 sidebarTitle: "Variant axes"
-description: "How is_variant_axis mirrors a native ProductOption and generates variants."
+description: "How a multi_select axis attribute mirrors a native Medusa ProductOption, and how products pick a subset of its values."
 ---
 
-In this document, you'll learn how an attribute becomes the axis a product's
-variants are generated from, and the mirror links that keep the two in sync.
+A variant axis is a `multi_select` attribute that a product varies along, such as Size or Color. Mercur doesn’t invent its own variant system: each axis is backed by a native Medusa `ProductOption`, so variants, carts, and orders keep working the way Medusa expects while operators manage sizes and colors as catalog attributes.
 
-## Variant-axis attribute
+<img className="block dark:hidden" src="/images/figures/attribute-variant-axis-light.svg" alt="The Size axis attribute maps each value to a Medusa option value, S to optval_01JD8Q1 and so on, and the Linen shirt selects only S and M, so its variants behind it are S and M." />
+<img className="hidden dark:block" src="/images/figures/attribute-variant-axis-dark.svg" alt="The Size axis attribute maps each value to a Medusa option value, S to optval_01JD8Q1 and so on, and the Linen shirt selects only S and M, so its variants behind it are S and M." />
 
-A `multi_select` attribute marked `is_variant_axis` is more than a descriptor.
-It defines a dimension along which a product varies, such as Size or Color. When
-such an attribute is created, the `ProductAttribute` model records the id of a native
-Medusa `ProductOption` in its `product_option_id` field, and each of its
-`ProductAttributeValue`s records the matching `ProductOptionValue` id in
-`product_option_value_id`.
+## The option mirror
+
+When you create a `multi_select` attribute with `is_variant_axis: true`, `createProductAttributesWorkflow` first creates a Medusa `ProductOption` (id prefix `opt`) titled with the attribute’s name. It then stores the option’s id on the attribute and each option value’s id on the matching attribute value.
+
+| Attribute side | Field | Medusa side |
+| --- | --- | --- |
+| `ProductAttribute` | `product_option_id` | `ProductOption` |
+| `ProductAttributeValue` | `product_option_value_id` | `ProductOptionValue` (id prefix `optval`) |
+
+The workflows keep the two sides in step. Renaming the attribute renames the option, and adding, renaming, or deleting values rewrites the option’s value list. Deleting the attribute deletes the option.
 
 ```ts
 await createProductAttributesWorkflow(container).run({
@@ -22,7 +26,7 @@ await createProductAttributesWorkflow(container).run({
     attributes: [
       {
         name: "Size",
-        type: "multi_select",
+        type: AttributeType.MULTI_SELECT,
         is_variant_axis: true,
         values: [{ name: "S" }, { name: "M" }, { name: "L" }],
       },
@@ -31,31 +35,49 @@ await createProductAttributesWorkflow(container).run({
 })
 ```
 
-Because the attribute mirrors a real `ProductOption`, the values a product
-selects along that axis are exactly what Medusa uses to generate its variants.
+This run creates the `Size` attribute, a global `Size` option with values `S`, `M`, and `L`, and three attribute values pointing at those option values.
 
-## Mirror links
+## Global options and exclusive options
 
-The attribute catalog and Medusa's product options are two separate modules, so
-the relationship is kept as a pair of **read-only mirror links**:
+Since Medusa 2.16, a product option can be shared by several products, and products attach to it. Mercur uses both kinds of option Medusa offers:
 
-| Mirror | FK on the attribute side | Points to |
-| --- | --- | --- |
-| Attribute → option | `ProductAttribute.product_option_id` | `ProductOption` |
-| Value → option value | `ProductAttributeValue.product_option_value_id` | `ProductOptionValue` |
+| Axis | Option created | `is_exclusive` | Shared by |
+| --- | --- | --- | --- |
+| Global axis attribute | When the attribute is created | `false` | Every product that attaches the axis |
+| Inline axis attribute | When it’s added to one product | `true` | Only that product |
+
+Medusa keeps titles of non-exclusive options unique, so two global axis attributes can’t share a name. Inline axes use exclusive options, so two products can each have their own “Cut” axis.
+
+## A product picks a subset of values
+
+A global axis holds every value the marketplace supports, but one product rarely uses all of them. When you attach the axis with `value_ids`, the workflow links the option to the product with only the matching option values, and it also links those attribute values to the product through the pivot link.
+
+```ts
+await createAndLinkProductAttributesToProductWorkflow(container).run({
+  input: {
+    product_id: "prod_01JD8Q1234567",
+    add: [
+      {
+        id: "pattr_01JD8Q1234567",
+        value_ids: ["pattrval_01JD8Q1234567", "pattrval_01JD8Q1234568"],
+      },
+    ],
+  },
+})
+```
+
+The product now has the `Size` option restricted to two values. You change the subset later with an `update` entry. The workflow moves the option values and the pivot links together.
 
-Both are 1:1 and have no pivot table. The foreign key lives on the attribute
-record itself.
+## Variants bind to the option by title
+
+Attaching an axis doesn’t create variants. You create variants yourself, and each one names its option values by option title, for example `options: { Size: "M" }`. Mercur’s `createProductsWorkflow` takes `attributes` and `variants` together, attaches the axes first, and then creates the variants against them.
 
 <Note>
-  The mirror links are **read-only**. They're resolved from the FK on the
-  attribute record; you never write the relationship through the link. The
-  workflows keep the option and the attribute in step whenever an axis attribute
-  or its values change.
+  A product with no axis still needs an option for Medusa to accept variants. `createProductsWorkflow` gives every new product a placeholder `__default__` option and removes it once a real axis is attached.
 </Note>
 
-<Tip>
-  Only `multi_select` attributes can be variant axes. The other four types
-  (`single_select`, `text`, `unit`, `toggle`) describe a product but never
-  generate variants.
-</Tip>
+## Related
+
+- [Create a variant axis and build variants on it](/platform/attribute/guides/create-a-variant-axis)
+- [The read-only mirror links](/platform/attribute/reference/links)
+- [Global and inline attributes](/platform/attribute/concepts/global-vs-inline)

package/content/platform/attribute/guides/attach-attributes-to-a-product.mdx

@@ -1,69 +1,112 @@
 ---
 title: "Attach attributes to a product"
 sidebarTitle: "Attach to a product"
-description: "Attach, detach, and update a product's attributes in one batch call."
+description: "Attach, detach, and update a product's attributes in one run of the batch workflow."
 ---
 
-In this guide, you'll learn how to manage all of a product's attributes from
-server code through a single batch workflow.
+Manage every attribute on a product from server code with one workflow, `createAndLinkProductAttributesToProductWorkflow`, the same engine behind the admin attribute batch route.
 
-Mercur exposes `createAndLinkProductAttributesToProductWorkflow`, the engine
-behind the product attribute batch endpoint. One call can attach new attributes,
-detach existing ones, and update selections, applied in the order
-**remove → add → update** so a same-call remove and re-add of one attribute
-resolves correctly.
+## Before you begin
+
+You need the following:
+
+- **A product**: the id of a product in the shared catalog, such as `prod_01JD8Q1234567`
+- **Global attributes**: the ids of the catalog attributes and values you want to attach, created as in [Create a catalog attribute](/platform/attribute/guides/create-an-attribute)
 
 ## Run the batch workflow
 
-```ts title="src/api/custom/products/[id]/attributes/route.ts"
-import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
-import { createAndLinkProductAttributesToProductWorkflow } from "@mercurjs/core/workflows"
-
-export async function POST(req: MedusaRequest, res: MedusaResponse) {
-  await createAndLinkProductAttributesToProductWorkflow(req.scope).run({
-    input: {
-      product_id: req.params.id,
-      add: [
-        // Existing select attribute: link chosen values
-        { id: "pattr_material", value_ids: ["pattrval_cotton"] },
-        // Existing text / unit / toggle attribute: set a scalar
-        { id: "pattr_thread_count", value: 400 },
-        // Inline attribute created and attached in one step
-        { title: "Gift wrap", type: "toggle", value: true },
+<Steps>
+  <Step title="Send add, remove, and update in one input">
+    The workflow applies `remove`, then `add`, then `update`, so removing and re-adding the same attribute in one run works.
+
+    ```ts title="src/api/admin/catalog-import/products/[id]/route.ts"
+    import type { MedusaRequest, MedusaResponse } from "@medusajs/framework/http"
+    import {
+      createAndLinkProductAttributesToProductWorkflow,
+    } from "@mercurjs/core/workflows"
+
+    export async function POST(req: MedusaRequest, res: MedusaResponse) {
+      await createAndLinkProductAttributesToProductWorkflow(req.scope).run({
+        input: {
+          product_id: req.params.id,
+          add: [
+            { id: "pattr_01JD8Q1234561", value_ids: ["pattrval_01JD8Q1234561"] },
+            { id: "pattr_01JD8Q1234562", value: 400 },
+            { title: "Gift wrap", value: true },
+          ],
+          remove: ["pattr_01JD8Q1234563"],
+        },
+      })
+
+      res.sendStatus(200)
+    }
+    ```
+
+    The first entry picks a value of a select attribute, the second sets a `unit` attribute to `400`, and the third creates an inline `toggle` attribute on this product.
+  </Step>
+  <Step title="Read the attributes back">
+    A product holds its selections as linked values. Read them through the `product_attribute_values` link, and read inline attributes through `scoped_attributes`.
+
+    ```ts
+    const query = req.scope.resolve("query")
+
+    const { data: [product] } = await query.graph({
+      entity: "product",
+      fields: [
+        "product_attribute_values.name",
+        "product_attribute_values.attribute.name",
+        "scoped_attributes.name",
       ],
-      remove: ["pattr_legacy_field"],
-      update: [{ id: "pattr_color", add: ["pattrval_blue"], remove: ["pattrval_red"] }],
-    },
-  })
+      filters: { id: req.params.id },
+    })
+    ```
 
-  res.sendStatus(200)
-}
-```
+    Inline attributes also show up under `product_attribute_values`, because their values link to the product the same way.
+  </Step>
+</Steps>
 
-## The three operations
+## Choose the add form
 
-Each entry in `add` is one of the `ProductAttributeBatchAdd` forms:
+Each `add` entry is a `ProductAttributeBatchAdd`. The keys you pass decide what the workflow does:
 
 | Form | Shape | Effect |
 | --- | --- | --- |
-| Existing select / axis | `{ id, value_ids }` | Links the referenced values to the product |
-| Existing text / unit / toggle | `{ id, value }` | `text`/`unit` create and link a value; `toggle` links the seeded `true`/`false` value |
-| Inline axis | `{ title, values, is_variant_axis: true }` | Creates an exclusive option, a scoped attribute, and the value mirror |
-| Inline non-axis | `{ title, type, value \| values }` | Creates a scoped attribute plus its value(s) and links them |
-
-`remove` takes attribute ids to detach; `update` carries
-`ProductAttributeBatchUpdate` entries adjusting an existing selection.
-
-<Note>
-  For a variant-axis attribute, `value_ids` is the per-product **subset** of the
-  mirror option's values. The product's variants are generated from exactly that
-  subset. See [Variant axes](/platform/attribute/concepts/variant-axes).
-</Note>
-
-<Tip>
-  The batch workflow composes the lower-level
-  `addProductAttributesToProductWorkflow`,
-  `removeProductAttributesFromProductWorkflow`, and
-  `updateProductAttributesOnProductWorkflow`. Reach for those directly when you
-  only need one of the three operations.
-</Tip>
+| Existing select | `{ id, value_ids }` | Links the chosen values to the product |
+| Existing axis | `{ id, value_ids }` | Attaches the global option with only those values, and links the values |
+| Existing text or unit | `{ id, value }` | Creates a value named `String(value)` and links it |
+| Existing toggle | `{ id, value }` | Links the seeded `"true"` or `"false"` value |
+| Inline attribute | `{ title, type?, value }` or `{ title, type?, values }` | Creates a product-scoped attribute and its values, and links them |
+| Inline axis | `{ title, values, is_variant_axis: true }` | Creates an exclusive option, a scoped `multi_select` attribute, and the mirrored values |
+
+## Change a selection with update
+
+An `update` entry targets one attribute by `id`. What `add` and `remove` mean depends on the attribute:
+
+- **Global select or axis**: `add` and `remove` hold attribute value ids, and an axis also moves the option values
+- **Global select or axis, full set**: `value_ids` is the complete set the product should hold, and the workflow works out the difference
+- **Inline axis**: `add` holds new values such as `{ value: "XL" }`, and `remove` holds attribute value ids to delete
+- **Text, unit, or toggle**: `value` replaces the current value
+- **Inline rename**: `title` renames an inline attribute, and it’s ignored for global ones
+
+```ts
+update: [
+  { id: "pattr_01JD8Q1234561", value_ids: ["pattrval_01JD8Q1234562"] },
+  { id: "pattr_01JD8Q1234564", title: "Fit", add: [{ value: "Relaxed" }] },
+]
+```
+
+The first entry swaps the product to a different value. The second renames an inline axis and adds a value to its exclusive option.
+
+## Handle a required attribute
+
+Removing an attribute with `is_required: true` fails with a `NOT_ALLOWED` error, and nothing in the run is applied. The check skips attributes you remove and re-add in the same run, so you can replace a required attribute’s selection in one call.
+
+## Route vendor edits through review
+
+Running the batch workflow writes to the product immediately. For changes a store makes, run `productEditUpdateAttributesWorkflow` with the same `add`, `remove`, and `update` plus `created_by`. It stages a product change for review, and the change runs the batch workflow when it’s confirmed. See [Product edits](/platform/product-edit/overview).
+
+## Next steps
+
+- [Create a variant axis and build variants on it](/platform/attribute/guides/create-a-variant-axis)
+- [Every attachment workflow and its input](/platform/attribute/reference/workflows)
+- [The links behind product attributes](/platform/attribute/reference/links)