Location capacity import lets you set the unit capacity of many locations at once by uploading a file, instead of typing values into the Location Capacity tab one cell at a time.

The values it writes are exactly the ones a user can enter by hand, and they drive the same capacity check: after a run, Toolio trims recommended transfers that would push a location past its capacity. See Location Capacity in Allocation for how capacity, the check window, the threshold, and the cuts work.

The importer is the practical way to maintain capacity at scale. When capacity is partitioned by product hierarchy, a single store can have thousands of combinations — the tab is for spot edits, and the file is how capacity actually gets loaded and kept current.

Use the location capacity import when:

Two things must be settled before the first file, because both decide what the file has to look like.

Location Capacity must be enabled for your organization. Without it, the Location Capacity tab is hidden and no capacity run happens. Contact your customer success manager to turn it on.

The capacity partition grain must be set first. The Capacity Partition Grain in Settings > Module Settings > Allocation > Allocation Configuration decides whether capacity is one number per store or one number per store and hierarchy combination — and therefore which columns your file needs. The importer never changes the grain; it only reads it.

The file is processed in the background and appears in the import list with its row and error counts, like any other import — see Manual Imports and Import Status and Error Diagnostics.

You can also drop the file on your SFTP for an automated feed. Toolio routes it to the location capacity importer when the filename contains any of the following (case-insensitive):

Examples: location_capacity_2026_spring.csv, nightly-location-capacity.csv

Each row is one capacity value: a location, one value for each level of the capacity partition grain, and the unit capacity.

Toolio matches your headers to the columns below by name, so a file that uses these names as headers imports without any setup. A column is recognized either by its attribute name or by its display name — location_external_id and Location External Id both resolve. Column order does not matter, and any column Toolio does not recognize is ignored, though it is kept with the row for error reporting.

The capacity_units column must be present in the file even when you are only clearing values — a blank cell is the instruction to delete, so the column has to be there to carry it.

Copy one of the samples below into a spreadsheet, replace the values with your own, and save it as a CSV whose name contains location_capacity.

This is a file for an organization whose Capacity Partition Grain is Division then Department. Every row carries a value for both levels.

Reading the sample:

When no partition grain is configured, capacity is a single number for the whole location and the file carries only two columns.

Each row resolves to one cell — one location and one combination — and the value in capacity_units decides what happens to it.

Two consequences are worth holding on to.

Absent is not deleted. A file only changes the cells it names. You can load one division's capacities without disturbing any other, and a new store entered by hand stays as entered until the file catches up with it.

Last write wins. An imported value replaces a value a user typed into the Location Capacity tab, and a value typed into the tab replaces an imported one. Neither is protected from the other.

Two rows that name the same location and the same combination address the same cell:

Unintended duplicates are usually a sign that the file carries a hierarchy column the grain does not partition by — for example a Class column in a file for a Division and Department grain. Those rows collapse onto each other, because the extra column is not part of the cell's identity. Remove the column, or add that level to the grain.

Invalid rows are reported individually with the uploaded row echoed back, so you can correct the file and re-import. The rest of the file still loads.

When one of these is hit, nothing is written and the whole file is skipped.

The location and capacity columns are checked first, so a file missing both those and a grain level reports the location and capacity columns only; fix them and re-import to see the rest.

A missing level is a whole-file error on purpose. Every row in a partial file would be written at a shallower scope than the one configured, and each row would look perfectly correct on its own — so the file is refused rather than half-applied.

Imported capacity behaves exactly like capacity entered by hand:

To apply new capacities immediately, use Recalculate Capacity Constraints in the ⋮ menu on the Recommended Transfer Orders screen. The action is permissioned — if you do not see it, ask your administrator for the Recalculate Capacity Constraints permission on your role. Then open Capacity Summary from the same menu to see where the run landed: which locations and partitions are over, how many units were cut, and how much overage remains.

No. Only the combinations the file names are touched, and everything else keeps its current value. Deleting is always explicit: list the location and combination with a blank capacity_units.

No. 0 rejects the row, because zero reads as "no capacity defined" everywhere downstream rather than as a real limit. To remove a constraint, leave capacity_units blank, which deletes the value.

No. A file with Division before Department writes to exactly the same combinations as one with them the other way round. Toolio matches on the header name, not the position.

No. Every level in the Capacity Partition Grain must appear as a column, and every row must carry a value for each of them. A file missing a level is rejected whole.

Yes. The most recent write wins, whether it came from the tab or from a file. There is no protection on manually entered values.

No. Capacity values are stored against the hierarchy values themselves, so renaming or reordering levels in the hierarchy leaves them in place. Only a change to the Capacity Partition Grain deletes values, and only the ones that no longer match it.

Check the import's error count first — a file whose location IDs or level values do not resolve can reject every row while still reporting as processed. If the rows were accepted, make sure the capacity check has actually run since: imported values only affect transfers after a nightly run or a Recalculate Capacity Constraints.

Yes. Drop the file on your SFTP with location_capacity in the filename and it routes to this importer on its own, on whatever cadence you send it.