The Workflow module has been upgraded with a new engine built for reliability and visibility at scale. Starting September 1st, 2026, the new module is live for all accounts.

Monitoring Dashboard

A new Monitoring tab is now available under Automation > Workflows. It gives a complete execution history for all workflow runs, showing which workflow ran on which Shipment Order, the execution status per run (Matched, Not Matched, Applied, or Failed), and a detailed Execution Details drawer showing every condition evaluated and every action applied — including the actual values and a full breakdown of what happened at each step. Every field change and tag update is now fully traceable, directly from the workflow run.

Performance

The new engine handles workflow triggers reliably at any volume — during busy import windows, API-heavy operations, and the highest-traffic periods. A key architectural improvement: the new engine runs a single query per order regardless of how many conditions are configured, keeping execution fast and consistent even as workflow complexity grows.

New Builder UI

The Workflow Builder has been redesigned with three new additions: Pre-built Templates — a curated library of ready-to-use workflow setups accessible from the builder header, each including a name, complexity badge, description, and a full preview of its trigger, conditions, and actions before applying; a Complexity Indicator — a real-time score and badge (Simple / Moderate / Complex / Very Complex) displayed in the Summary Panel as the workflow is built; and a Summary Panel — a sticky right-column panel showing live counts of conditions, actions, and rule groups against their limits, plus form validation and inline warnings.

What Stays the Same

All existing workflows, triggers, conditions, actions, send email configurations, tags, and priorities carry over automatically — no action is required. Important: workflows above the new limits (40 conditions per rule group, 40 actions per workflow, 350 rule groups per workflow) are grandfathered — they continue to run as configured and can be adjusted at the account’s own pace.

Replenishment Wave Rules now support a Soft Allocation mode that prevents the target-location suggestion engine from directing multiple open replenishment tasks to the same location before any of them are completed. When enabled, the suggestion logic treats other non-completed tasks’ already-suggested target locations as if that inventory were already placed there, so a location already claimed by one task is skipped when the next task is suggested a destination.

A new “Enable Soft Allocation for Dynamic Replenishment” toggle is available on the Replenishment Wave Rule setup screen, defaulting to on for newly created wave rules and off for existing ones unless explicitly enabled. (52302, 52303, 52304)

For more information, please check the related knowledge base article.

Putting away a license plate (LP) is now protected against accidental location conflicts. Previously, if two operators were given a putaway suggestion, the system had no way of knowing a location was already about to be filled, so both could end up pointed at the same spot.

Now, the system keeps a temporary record of each in-progress suggestion: if you request another suggestion for the same LP, it updates that same record instead of creating a conflicting one, and the record automatically clears itself once the placement is confirmed. This brings the same protection already used for sequential LP putaway to single-LP putaway. The change happens entirely behind the scenes — the Directed LP Putaway screen and the Receiving screen's "Suggest Putaway Location" option look and behave exactly as they did before. (52279, 52281)

A new client-level “Allow Different Location/LPN” setting lets pickers scan a different source location, LPN, lot number, expiry date, or production date than what a task originally specifies, instead of being blocked outright. When enabled, the mobile Pick to Location, Full LP Picking, Pick and Sort, and Pick Specific Order flows validate the scanned alternative against the location/LPN, prompt for any required tracking attributes, and hand off to a new backend validation chain before the swap is allowed.

On the backend, Shipment Order Type gains configurable swap thresholds — an expiry date and production date tolerance in ± days, plus a lot number pattern (via direct regex, or mapped per Product Type or Product Group) — so swaps are only accepted within the tolerances a warehouse manager defines. Every swap also re-checks the order’s allocation algorithm conditions (inventory attributes and location criteria) so a substituted pick still satisfies the original order’s requirements. (51911, 51913, 51914, 51915, 51916, 51917, 52517)

Bulk and single execution/cancellation of Picking and Packing tasks now enforce a consistent set of pre-action checks: all selected tasks must share the same task type and warehouse, tasks already Canceled or Completed are rejected, and tasks with an open Pick Short or Pack Short cannot be executed. Bulk requests are capped at 100 tasks and are transactional — if any task in a batch fails validation, the entire batch rolls back, with an Attention popup listing the failed tasks (Task ID, Order Code, SKU, Qty, reason) and an “Execute/Cancel Remaining Tasks” option to proceed with only the valid subset in one click.

Cancellation additionally evaluates the order’s Create Backorder / Allow Partial Allocation configuration to decide whether the order becomes partial, spins off a linked backorder, or is blocked outright when neither option is enabled. Packing execution also enforces the Enable Partial Order Packing setting (with an exception when only one Pending packing task remains) and skips the manual serial-number prompt for serial-tracked items during execution. (51792, 51793, 51794, 51795, 51796, 51798)

The Carrier Errors monitoring page (Carrier Monitoring > Carrier Errors) has been extended with a new Void/Cancel Label tab, giving integration users the same drill-down visibility already available for Label Generation and Rate Call failures. New backend services retrieve Void Label request and response payloads and the Transaction Details drawer now displays live data instead of placeholder content across all three tabs. The Label Generation and Rate Call grids also gain three new columns — Destination Type, Label Type, and Rate Shopping Name — surfacing existing return/international/rate-shopping flags without requiring users to inspect raw payloads (52140, 51564, 52145, 52137, 51263, 52208)

Shipment orders routed through EasyPost can now request a signature or delivery confirmation type — such as adult signature or no-safe-drop — matching the confirmation capability already available on other integrated carriers. The existing Confirmation Type selector on the shipment order is now wired into the EasyPost label creation request. (51742)

18 new standalone webhook events have been added for specific inventory actions previously managed only through the InventoryMovementRecorded event. You can now subscribe to individual event types independently, receiving only targeted payloads to streamline payload processing and reduce transaction noise. Explore the full capabilities of our new platform in the Webhook V2 Documentation

List of Newly Added Events :

Note: The "InventoryMovementRecorded" event itself is unchanged and continues to fire for all action types. (51965, 51966, 52046)

Logiwa IO now supports Split Month Storage as a new Fee Calculation Type for monthly pallet storage billing.

For Billing Contracts with a Monthly frequency, you can select Split Month Storage when creating or editing a Storage fee. Once selected, Fee By and Charge By are automatically set to LP.

The Split Month Settings section allows you to configure:

• Split Day of Month

• Standard Rate

• Alternate Rate

The Split Day determines which rate is applied to the initial storage charge. Pallets received on or before the configured Split Day use the Standard Rate, while pallets received after the Split Day use the Alternate Rate. In subsequent months, eligible pallets remaining in storage are charged the Standard Rate as Recurring Storage.

Existing Minimum Price, Maximum Price, and Conditions can also be used with Split Month Storage.

Billing reports provide separate results for initial storage before and after the configured Split Day, as well as Recurring Storage, making the calculated charges easier to review and use for invoicing. (47190)

Five integration articles have been published, covering new returns, order, and accounting integrations:

​Loop Returns Integration
Automates the return lifecycle between Loop Returns, Shopify, and Logiwa — Loop returns are automatically created as Logiwa Return Orders (RMAs), processed at a dedicated Return Station, and synced back to Loop as accepted or flagged for merchant review. Includes support for exception scanning (damaged, empty box, wrong item, missing components) and automatic return cancellation sync.
For more information, please check the article: Loop Returns Integration

​Magento Integration
Adds a self-onboarding Magento sales channel connection supporting order download, product catalog sync, sellable inventory sync, and shipment/tracking confirmation back to Magento — including automatic breakdown of Configurable, Grouped, and Bundled products into simple SKUs.
For more information, please check the article: Magento Integration

​CartRover Integration
Provides bidirectional data exchange with CartRover, letting CartRover continue communicating with its connected sales channels while Logiwa manages fulfillment — including order sync, product sync with Kit-to-Order support, inventory sync (with Net Kitting Capacity for kits), shipment confirmation, and order cancellation. Supports CartRover Product Aliases so multiple channel-specific SKUs can resolve to a single Logiwa master product.
For more information, please check the article: CartRover Integration

​Walmart Marketplace Integration
Connects a Walmart Seller Fulfilled account to Logiwa for order creation, product sync, inventory sync (with Net Kitting Capacity for kit products), and shipment confirmation. Includes Product Listings support for non-matching Walmart/Logiwa SKUs via direct SKU match, manual mapping, or UPC/barcode-assisted Product Sync matching.
For more information, please check the article: Walmart Marketplace Integration

​QuickBooks Online Integration
Connects a QuickBooks Online company file to Logiwa for order import, invoicing, inventory adjustments, purchase order sync, and receiving/billing workflows — including automatic Vendor Bill/Sales Invoice generation on receiving, BOM-based kit resolution on fulfillment invoices, and billing sync from approved Logiwa billing calculations.
For more information, please check the article: QuickBooks Online Integration

• Added a Mezzanine field to the Location Master — available on the Create/Update sidebar, Excel import/update/export, and Grid List — so customers with multi-tier storage layouts can tag mezzanine-level locations. (52243, 52244, 52245)

• Added the Capacity Mode and Maximum Capacity Quantity fields to the Location Import/Update Excel Field Description sheet, documenting accepted values and conditional requirements for bulk location configuration. (52082)

• Extended the Company Name field — previously available only on the standard Pack List — to the Retailer Packing List, Task-Based Packing List, Picking List, Consolidated Picking List, and Job Picking List data sources, and added a new Billing Address Company Name field across all six report types. (52102)

• Shipment Order Code changes are now recorded in the changelog with the old value, new value, timestamp, and the user who made the change — previously Code changes were silently excluded from the changelog while other field changes were tracked. (52107)

• Added logging to the Packing Slip print path (report design used, resolved template, applied filters, and job/order/client/warehouse identifiers) to support investigating reports of Pack List and Carrier Label print sequences not matching during bulk job printing. (52110)

• Added “Select 25” and “Select 50” quick-select controls to the Shipment Order screen, letting warehouse managers select the next 25 or 50 unselected orders from the current filtered/sorted list in one click instead of selecting each row individually to build a batch. (52124)

• Implemented a single source of truth for carriershippingoption and carriersetupshippingoption tables, resolving cross-screen inconsistencies where a shipping option was visible on the Carrier Setup screen but missing or stale in Shipment Order, Workflow and Rate Shopping. (51437)

• Reclassified Lob address verification responses with an empty confidence score as Invalid Address instead of “Verified with Warning,” preserving the original shipment address instead of overwriting it with an unreliable value. (52043)

• Added the ability to view and download the order payload behind a Missing Shipment Order error directly from the Channel Monitoring grid, for Shopify, Amazon, WooCommerce, and ShipStation. (51968,52174)

• Extended Manufacturer Product Identifier and regulatory detail mapping to FedEx Create Label requests, so qualifying cross-border shipments from a non-EU origin to an EU destination automatically carry the compliant customs data already stored on the product. (51847)

• Added Asendia as a supported carrier in the EasyPost integration, making it available to eligible customers with a configured Asendia EasyPost account. (52356)

• Extended Techship's carrier and service level override logic to every Techship shipment, so shipment records and printed labels always reflect the more accurate carrier/service data returned in the Techship rate or label response. (52038)

• Added ShipFrom/ShipTo Tax Type and TaxID as selectable fields in the Carrier Setup Label Messages and Commercial Invoice No Reference dropdowns, enabling tax identifiers to be printed on carrier labels and customs documents for international shipments. (51865)

• Improved download orders run by processing the orders in smaller batches, allowing them to appear in Order Backlog progressively instead of waiting for the full download to complete. Integration History behavior remains unchanged and continues to summarize each download as a single entry. (51937)

• Added JumpCloud as a new single sign-on (SSO) provider option in the SSO Setup screen. (52164)

• Added the PO Code to the subject line of purchase order notification emails, making them easier to identify. (52238)

• Increased the Purchase Order line-item capacity to at least 2,000 SKUs per transaction, eliminating API and integration timeouts when receiving high-line-count Purchase Orders. (51997)

• Resolved an issue where certain calculation operations in Billing could fail on large data volumes. (51580)

• Improved Amazon Integration Methods to reduce excessive memory usage and improve overall system stability. (52246)

• Optimized SQL queries used in Shipment Billing Calculations to resolve timeout issues. (52353)

• Fixed an issue where the system allowed operators to change the location of an occupied Parent or standard License Plate during mobile Transfer or Directed Putaway, by correctly blocking location changes on LPs that already hold inventory. (52262)

• Fixed an issue where deleting a product’s pack type also hard-deleted the associated historical Inventory Snapshot records, destroying real historical inventory data instead of just removing the pack type. (52247)

• Fixed an issue where searching by PO code or vendor on the mobile Receiving Search & Select PO screen incorrectly returned Completed purchase orders alongside Pending and Started ones. (52230)

• Fixed an issue where the Store filter on the Return Orders screen did not correctly filter results, and blocked other filters from working correctly when applied afterward. (52122)

• Fixed an issue where the Product Bulk Import process did not validate the Expiry Date Format column, allowing unsupported values to be imported and later causing blocking errors during inventory operations. (52109)

• Corrected the Add/Edit Hierarchical Pack Type modal’s unit dropdowns to show “Select an option” instead of a false default selection, while correctly displaying previously saved units in edit mode. (52266)

• Fixed an issue at the Packing Station where an order change that included product-level changes — even when bundled with a store-level (customer) change — was still shown with the “Cancel Requested” option available; the backend now flags whether a change originated purely from the store at the order level, and the UI correctly restricts mixed or product-level changes to “Store Changes for the order” only. (51748, 52085)

• Fixed an issue where the Packing List printout rendered an empty <root></root> tag instead of the warehouse address. (52023)

• Fixed an issue where cancelling a picking job with zero associated tasks failed silently instead of completing or returning a clear error. (52027)

• Fixed an issue where the Shipment Order Code (SOCode) shown on Transaction History became stale after an order was renamed — each transaction now snapshots the order’s code as it was at that transaction’s own creation time, and past transactions are not retroactively altered by later renames. (52108)

• Fixed an issue where the Scanned Items count always displayed 0 on the Pack Short label. (52429)

• Fixed an issue where the line-level Canceled Quantity was calculated incorrectly after an unmerge, causing shipment failures on Merge → Unmerge → Merge chains. (52464)

• Corrected packed quantity calculations in Billing for shipment orders with matching shipment history entries. (52290)

• Fixed an issue that prevented editing the Company Name for newly created accounts. (52207)

• Fixed an issue where password policy requirements were not enforced when creating users through the API or Excel import. (50223)

• Fixed an issue where updating the Company Name on a newly created account. (52207)

• Fixed an issue where Full LP Allocation could split a license plate (LP) when no combination of whole LPs could exactly satisfy the required order quantity. The system now correctly honors the order's partial allocation setting instead of forcing a split. (52405)

• Fixed an issue that caused the search and filter functionality inside pop-up and sidebar screens to stop returning results across the system. (52472)

• Extended the Mezzanine field to the Open API Location Create, Create Bulk, Update, Get, and List endpoints (v3.2 create/update/get, v3.1 list), keeping internal and external schemas in sync. (52243)

• Added new Open API endpoints to create, update, and retrieve License Plates by identifier, and extended the License Plate Type endpoints to return warehouse code and human-readable unit labels alongside the existing numeric unit IDs. (52206, 52205, 52099, 52081)

• Made the sku field optional on the Product Listing Upsert Open API endpoint (PUT /v3.1/Product/listing), allowing sellers to register a listing before a SKU has been assigned, while all other required fields and SKU-based matching rules remain unchanged when sku is provided. (52236)

• Added “in” operator support for ChannelProductIdentifier, ProductSKU, and ChannelProductSKU on the List Product Listings Open API endpoint, allowing integrators to batch-lookup multiple listings in a single call instead of issuing one request per value. (52126)

• Added an optional forceUomPackType field to the shipment order line schema on the Create Shipment Order and Create Shipment Order Bulk Open API endpoints, letting integrators default to a product's own UOM pack type without looking up and sending it explicitly. (52128)

Known Issue: The forceUomPackType field also appears in the "Update Shipment Order" and "Update Shipment Order Bulk" endpoints due to a shared mapping schema. Please note that this field is currently non-functional for update requests and will be fully supported in the October release.

• Added the isEnablePackageSuggestion parameter to the Client Create/Update Open API endpoints. (52105)

• Added ShipmentOrderIdentifier and ProductIdentifier as response fields and filter criteria on the Transaction History list, export, and Open API endpoints, so records can be reliably traced back to their originating order and product. (52106)

• Began extending Transaction History with additional stable identifiers alongside its other mutable display fields (building on the ShipmentOrderIdentifier/ProductIdentifier work above), so records stay linkable to their source entities even after renames; the full set of fields in scope was still being confirmed with each owning domain team as of this release. (52134)

• Password policy is now enforced for user creation through the Open API. (50223)