Your New Assortment Plan can be built from files instead of by hand. Two imports do that work together: a choice file, which owns the choices and offerings in your plan, and the Variant Location Plan Metrics file, which fills those offerings with plan numbers at SKU × location × date.

These used to be one job. The metrics file created a choice whenever it met a SKU whose choice was not in the plan yet, and decided on its own which choice each row belonged to. Splitting the work in two means you decide which choices exist, and any metrics row that cannot be placed is reported with a reason instead of disappearing.

The grain is different in each file. The choice file is one row per choice. The metrics file is one row per SKU × location × date, exactly as it is today — see Importing Variant Location Plan Metrics into Assortment Plan for how those rows roll up to choice and cluster.

One row describes one choice, keyed on a Choice External Id that you control. An unknown id creates a choice, a known id updates it, and re-sending the same file changes nothing — so a full file is always safe to resend.

Toolio creates one offering per cluster in the Automated Cluster Group you name, and applies the row's dates and unit economics to each of them. Ids and names are matched ignoring case, accents, and surrounding spaces.

In Import History this import appears with the type Choice. If you deliver files over SFTP or another automated feed, the file name must contain choice or offering, and must not contain plm.

A blank cell leaves the stored value as it is. To clear a value, change it in the app — the file only writes what it carries.

Choices created by the import do not pick up New Assortment Plan defaults, so send the attributes you want on them in the file.

Excluded Locations and Manual Included Locations take store ids separated by a pipe (|), for example STORE-01|STORE-02|STORE-07.

Each store is written to the offering of the cluster it belongs to, so a list spanning two clusters lands on two offerings. A manually included store only restores one that a rule or a location list had removed.

A filled column replaces that list on every offering of the group's clusters. A blank column leaves the existing lists untouched. Offerings kept for clusters that have since left the group are not changed.

The lists are never written partly. If a store on the row has no offering to land on, or the write fails, the choice itself is still saved and the row reports that its lists were not.

If the Choice External Id already exists, that choice is updated. If it does not, Toolio looks for a choice to adopt before creating a new one — a choice that was created without an external id, by the legacy metrics flow or in the app.

A choice is adopted when the Actual Choice and Automated Cluster Group on your row identify exactly one of them. If more than one candidate remains, the row is rejected and the candidates are listed, so you can resolve it rather than end up with a duplicate.

Every rejected row is reported with a reason you can act on. The rest of the file still loads.

With the flag on, every metrics row is placed through its variant's Actual Choice. For each choice of that actual choice, Toolio looks up the row's store in that choice's own cluster group and partition, and the choice's offering for the store's cluster becomes a candidate.

Rows that land on the same offering and date are summed, and the result is written to the plan scenario — the same scenario that powers the Plan columns in New Assortment Plan. Size-level metrics are written the same way, at choice × size × date.

Skipped rows are counted by reason on the import, and the total appears in the import's skipped line count.

Open Import History and select the run to see its details page, where the skipped counts above appear alongside the row counts and any rejected rows. See Viewing & Managing Data Imports for the grid, the details page, and how to share a link to a specific run.

[Screenshot: Import Details page for a Variant Location Plan Metrics run, showing skipped reasons with their line counts]

Choices and offerings the choice file writes carry the import job that last changed them, so you can trace any row in the plan back to the file it came from.

Only if the flag is on — and then yes, for every choice you expect to plan. With the flag off, the metrics import still creates choices as it always has.

They stay and keep their plan. The first time your choice file names one of them, Toolio adopts it rather than creating a duplicate, as long as the actual choice and cluster group identify exactly one.

With the flag off, yes — the mapper still offers importable choice attribute columns. With the flag on, those columns are no longer offered, because the new flow writes nothing to the choice. Send them in the choice file instead.

Names are matched against published cluster group snapshots, the same list the grid's dropdown shows. A draft with the same name is not a match, and a name shared by two snapshots is rejected rather than guessed.

No. It creates and updates choices and offerings, and replaces store lists on the clusters of the group it names. It never deletes a choice or an offering, and it leaves offerings for clusters that have left the group alone.

Nothing. A blank leaves the stored value as it is, which is what makes a full resend safe. Change a value by sending the new value, or edit it in the app.

Usually because the choices do not exist yet. Check the skipped reason on the import — "No choice exists for the variant's actual choice" means the choice file has not run for those products.

No. That change is rejected, because the cluster group is part of the choice's identity. Use a new Choice External Id to plan the same product against a different group.