Stock Reservations in a Business App: When Should an Item Stop Being Available?
Decide which business event reserves stock before commissioning an ordering or job-management app. Adding an item to a draft, accepting a quote and confirming an order are different events. Your app should make clear which one reduces availability, how long a temporary hold lasts and what releases it. A quantity physically in the building is not necessarily a quantity you can promise to another customer.
This guide concerns allocating goods to work, not converting packs into pieces, scanning labels or taking payments. The design suggestions are commissioning recommendations. Shopify's documentation is used as a concrete example of inventory states, not as a claim that every system works the same way.
Give the quantities separate meanings
Ask for plain-language definitions of physically held stock, stock already assigned to work, stock withheld from sale and stock still on its way. Do not let a single “in stock” label cover all four.
Shopify's inventory-state documentation defines available inventory as sellable stock that is neither committed nor unavailable, and excludes incoming stock. Its on-hand total includes committed, unavailable and available quantities. These are Shopify's definitions; your custom app needs its own equally explicit agreement.
The practical distinction matters. A damaged item can still be on the shelf without being usable. A promised item can still be in the warehouse without being free for another order. Goods expected tomorrow are not goods received today. If you deliberately allow advance orders, describe that as a separate promise rather than disguising incoming quantities as present stock.
Choose the reservation event
Write a short timeline for your real workflow. Does a quote reserve anything? Does staff approval reserve the item, or only a confirmed order? Must the customer choose a collection location first?
Shopify describes committed quantities as units set aside that cannot be sold, including unfulfilled orders, reservations in draft orders and transfers marked ready to ship. That is a useful example of why “draft” alone does not tell you whether a reservation exists.
For your own app, recommendation: make the state visible next to the work record. “Draft, no stock held” and “Reserved until the displayed expiry time” convey different promises. If a hold expires, decide whether the customer must recheck availability before continuing. Do not leave an expired promise on a confirmation screen.
Release the hold without inventing stock
Agree what cancellation, reduced quantities and substitutions do. Releasing an unfulfilled reservation is not the same as receiving returned goods. If an item has already left the premises, cancellation should not magically put it back on a shelf.
Ask who confirms a return's arrival and condition before it becomes available. Shopify's distinction between unavailable and available stock illustrates why a received item may still need to be withheld. Its incoming-stock documentation also notes that apps may place received goods into states other than available, such as safety stock. Receipt and permission to sell are separate ideas.
For a partially fulfilled order, ask the developer to demonstrate that only the unfulfilled allocation is released when the remainder is cancelled. Keep a visible explanation of the adjustment so staff can understand what changed.
Test the last item, not just a comfortable surplus
A hypothetical acceptance scenario is two staff members trying to reserve the same last available item from separate screens. For a no-overselling policy, require one reservation to succeed and the other to receive an honest unavailable result. A fresh-looking screen is not itself proof that the saved reservation is valid.
This is a requested outcome, not an implementation guarantee supplied by the Shopify page. The developer must choose and test the server-side mechanism, including retries and other stock-changing channels. If the website, counter and warehouse operate in separate systems, list which system owns the authoritative availability and what happens when synchronisation is delayed. Do not promise immediate consistency merely because an integration exists.
What to put in the brief
Bring these cases into the app's acceptance criteria:
- A draft that does not reserve stock leaves availability unchanged.
- A successful reservation reduces the amount that others can reserve at the correct location.
- An expired temporary hold is released once, and continuing requires the agreed availability check.
- Cancelling unfulfilled work releases the appropriate allocation, not goods already dispatched.
- Returned goods do not become sellable before the agreed receipt and condition decision.
- Two competing reservations for the last item obey the no-overselling policy.
- A delayed external stock update produces the agreed warning or restriction rather than an invented certainty.
The useful deliverable is a documented reservation lifecycle demonstrated with test records, not simply a stock counter. In a business-app project discussion, start with the event at which your team promises the goods and the event that ends that promise. Those two decisions shape the rest of the feature.