# Policies

Source: https://docs.tightly.io/help/replenishment/policies
Reviewed: 2026-09-07

## The question this page answers

Which replenishment rules run my restocking: what does each trigger on, how much does it order, which variants does it own, is it switched on; and can I write a new one and see how often it would have fired before I switch it on?

## What you see

A policy is a rule you write for a set of variants at your warehouses. Policies live under Settings › Policies on every tier, and the old addresses land there. A variant at a warehouse belongs to at most one policy, and while that policy is active, and inside its dates where it has them, the variant leaves Tightly's own recommendations and follows the rule instead. Every variant in no policy follows the built-in, Tightly's recommendation, which reads days of cover, lead time and profitability with every inventory run.

The list's head counts Variants covered, and a search by Policy name narrows it, with Clear search. The table is one row per policy, the built-in first, and the built-in row always stands. Its columns are Policy, Trigger, Orders, Covers and Status. Trigger reads Auto for the built-in, or the threshold as less than so many days or units, with Days of cover below or Stock level below a number on hover. Orders reads Auto for Tightly's recommendation, MOQ for the supplier's minimum, or so many units for a fixed quantity. Covers counts distinct variants, on one grain for the built-in too. Status is a mark, Active or Inactive on hover.

A row opens the policy's own page: its rule as one sentence, such as Active under 21 days’ cover, orders Supplier MOQ., a count of variants or products, and the one table of what it covers, by variant or by product with a search: Product, Variant, SKU, Category, Default supplier, Warehouse, Stock on hand and Cover, No forecast where there is none to walk.

The backtest appears beside the rule during creation and editing. It reports **Would have triggered**, **Never triggered in that window**, **Checking**, **Not available** or **Nothing to backtest**, according to the returned result. **Variants backtested** counts the variants actually walked, at most 200; it is not the number selected.

## What to do

A writing seat writes policies; a read-only seat reads them. New policy opens the create page: Name, Description, Replenish when (Days of cover or Stock level, and its number) and Order (Tightly’s recommendation, Supplier MOQ or Fixed quantity, and its quantity), then the picker, which offers variants with a supplier and no policy, a page at a time or every one in the view. Before the button it says what the press does, and Create policy is one write that creates the policy with its first variants and schedules an inventory run, so they follow the rule from that run. With nothing picked the button is Create with no variants, and an empty policy is allowed.

On a policy's page, Edit opens Edit the rule, the same fields in a drawer, and before Save it says:

> Checked with each inventory run. Recommendations require your approval before ordering.

Make inactive or Make active turns the rule off or on. Add variants opens the same picker in a drawer and adds more from the next inventory run; a variant already in another policy is refused. Remove on a row, or Remove {n} variants from this policy for a selection, takes variants back to Tightly's recommendation, with Undo in place for variants removed from the variant table. Delete policy asks first, saying it takes the policy's variants back to Tightly's recommendation and cannot be undone. The built-in cannot be edited, switched off or deleted, and says Tightly’s own policy is always active.

The refusal a variant in two policies meets is the server's sentence, in place, naming the variant, the location and the policy by their ids:

> Variant {variant} at location {location} is already in replenishment set {policy}.

## Season limits and saved changes

A policy does not grant permission to buy past a commitment's season. The policy’s **Commitment check** column shows allowed versus requested units, or **Order held**, with the evaluation date. The replenishment line also shows its season limit. Read that explanation before changing the rule. A hold can require better demand evidence or a different arrival date; it is not an instruction to increase the order.

**History** on a policy shows recorded rule and membership changes, their dates and the named actor where available. Opening the policy again reads the saved rule. Changes schedule an inventory run, so check the refreshed recommendation separately from the successful save. When you came from a commitment's replenishment queue, **Back to replenishment** returns there.

## When it is empty or failed

> The policies could not be read.

The read failed; Try again is offered.

> This policy could not be read.

The policy's read failed, with Back to policies; a 404 renders the server's own sentence.

Under the rule, the Backtest figure reads Not available when the check did not come back; the word stands in place of a figure, never a spinner.

> No variants in this policy.

Add variants is the door. A search that matches nothing reads No variants match this search., a list search No policies match this search., and a picker with nothing left reads No variants with suppliers left.