Reservations

Before you reserve

Confirm the exact slab identities and current availability. A reservation protects physical pieces, so use slab IDs/identifiers rather than a material description alone.

Where the customer work is project based, confirm the project and optional selection context first.

1. Create the reservation

The verified operational write accepts project_id, selection_id, slab_ids, hold_type, expires_at, reason and notes.

Use an expiry that matches the business hold policy so stock is not held indefinitely without review.

2. Verify the hold

After creation, confirm the expected slabs now show the reservation/hold state and that another eligible workflow cannot commit the same physical pieces.

The reservation is the operational protection layer; it should not be replaced by a note on a quote or opportunity.

3. Manage ownership and expiry

Release, cancel and extend are controlled actions. Acting on another employee’s hold can require additional override authority in the current environment.

Automated expiry depends on healthy queue/scheduler execution, so production system-health checks matter to reservation policy.

4. Link the commercial commitment

When the customer accepts the commercial work, link the reservation to the authoritative quote using the quote-link workflow. The operational API maps existing quote/quote-item context; it does not create another quote engine.

5. Move to allocation

Allocate from the eligible reservation/quote link so the accepted work owns the exact physical slabs.

If availability or workflow state changed before commitment, fail clearly and choose a replacement or revise the commercial record instead of forcing the status.

Concurrency control

Reservation and quote-acceptance flows must be safe when two users act on the same stock, when a transfer overlaps a commitment, or when a reservation expires during checkout. The server-side workflow is authoritative in these races.