Working in Inventory

Daily Operating Model

Inventory works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Create a product and stock it

1. Open Products and create the product master record.
2. Assign category, unit of measure, status, and searchable attributes.
3. Create variants when the product has size, colour, or other options.
4. Add product prices and default price where sales channels need them.
5. Open Stock and create or update stock in the correct store.
6. Review generated inventory transaction history.
7. Publish the product to Sales, Billing, or Shop only when stock and price are correct.
8. Use reports to confirm catalogue completeness.

Flow 2: Transfer stock between stores

1. Open Transfers and create a stock transfer.
2. Select source store, destination store, products, variants, and quantities.
3. Submit the transfer for approval if required.
4. Issue or ship the stock from the source store.
5. Receive stock into the destination store.
6. Confirm stock balances and transaction records for both stores.
7. Investigate shortages or damaged goods with adjustment records.
8. Close the transfer after both sides agree.

Flow 3: Adjust and audit stock

1. Open Adjustments or Inventory Audit for the target store.
2. Capture counted quantity, reason, and supporting notes.
3. Review difference between system stock and counted stock.
4. Submit adjustment for approval when required.
5. Post approved adjustment to create inventory transactions.
6. Use ActivityLog to audit who changed what and why.
7. Schedule cycle counts for high-value or high-movement products.
8. Feed persistent variance patterns into procurement or warehouse process changes.

Flow 4: Monitor replenishment and exceptions

1. Open Stock reports and filter low or out-of-stock products.
2. Review requests from teams that need stock.
3. Create purchase requisitions or transfers for replenishment.
4. Investigate products with negative or unexpected balances.
5. Check price history before publishing new selling prices.
6. Notify Sales or Shop when critical stock changes affect availability.
7. Use workflows to create tasks for low stock or failed transfer receipt.
8. Close exception tasks only after stock and transaction records match.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/inventory for namespace and intent details.