Skip to content

Warehouse — Workflow

Overview

Warehouse follows the standard catalog lifecycle in SARA. Locations and location types are created active and can be deactivated or reactivated as needed. There is no approval pipeline.

No approval pipeline

This feature does not have a multi-step approval workflow. Locations move directly between active and inactive with no intermediate statuses.

Note

For the standard catalog lifecycle pattern, see: Workflows & Pipelines


Status lifecycle

  • ACTV — Active. The location is available for inventory operations (entries, movements, requests).
  • INAC — Inactive. The location is excluded from selectors and cannot receive new stock.

Info

For system-wide status guidance, see: Status


Lifecycle notes

Deactivating a location is blocked if the location has active child locations. SARA checks the full descendant tree before allowing the status change. If active children are found, the user is shown the list and given the option to deactivate the parent and all active children in one action.

Activating a location checks whether any ancestor (parent, grandparent, etc.) in the location's chain is inactive. If inactive ancestors are found, the user is offered the option to activate them all together, since a location inside an inactive parent cannot be meaningfully used.

Location types follow the same ACTV ↔ INAC lifecycle. Deactivating a type removes it from the creation and edit forms but does not affect locations already using that type.

Warning

Locations in use by active inventory stock or ongoing inventory operations should not be deactivated without first moving or resolving the associated inventory. SARA does not block deactivation based on inventory state — this is an operational responsibility.


Setup & dependencies

Warehouse locations are a prerequisite for Inventory Management. Without at least one active location, inventory entries and movements cannot be registered.

Location types should be configured before creating locations. While SARA does not enforce a minimum set of types, having a clear type taxonomy (e.g., Room, Rack, Shelf, Bin) helps users model the physical storage structure consistently.


Permissions

Permissions

Access and actions are permission-driven. See: Permissions