Prioritizing Orders

Order prioritization lets you tell the app which orders matter most. Assign a priority of High, Standard, or Low to any order, and the app processes higher-priority orders first — through order routing, routing retries, and order-based automations. If you never set a priority, nothing changes: every order is treated as Standard and processed exactly as before.

Key capabilities:

  • Route urgent orders ahead of the rest of your queue in every routing run.
  • Apply the same ordering to retries — out-of-stock, stuck, and failed orders are retried High first.
  • Evaluate new-order and order-update automations for High-priority orders first.
  • Carry priority downstream automatically: shipping requests and fulfillments inherit the order's priority when they are created.

How it works

The app processes orders in recurring cycles (for example, order routing runs every few minutes). With order prioritization, each cycle works through orders in three passes:

  1. Pass 1 — High: eligible High-priority orders, oldest first.
  2. Pass 2 — Standard: eligible Standard orders and all orders with no priority set, oldest first.
  3. Pass 3 — Low: eligible Low-priority orders, oldest first.

Each cycle works through one priority level at a time. The app doesn't fetch any Standard orders until it has processed the High orders it picked up for that cycle, up to a per-cycle batch limit, and the same applies before Low. A backlog larger than one cycle's batch carries over to the next cycle — still ahead of lower-priority orders. The app tracks progress separately for each priority level, so a deferred order is never skipped, only processed in a later cycle.

A few important consequences:

  • A High order created after a Standard order is still processed first if both are waiting in the same cycle. This is the point of the feature — and it is also why priority breaks first-in-first-out (FIFO) processing.
  • Priority changes when an order is processed, never the outcome. A High order goes through exactly the same routing rules, inventory checks, and automation logic as any other order — it just gets its turn sooner.
  • Priority applies within each cycle. It cannot reach back in time: an order already routed in an earlier cycle is not affected by higher-priority orders arriving later.
  • Retries honor priority too. Orders being retried after an out-of-stock condition, a system error, or getting stuck are queued High, then Standard, then Low.
  • Under sustained volume, Low orders can wait a long time. If High and Standard orders continuously fill each cycle, Low orders may only be processed during quiet periods. If a Low order has waited too long, raise its priority.

If your operation depends on strict first-in-first-out processing, do not set priority on any orders — even one High-priority order is processed ahead of earlier Standard orders. The app also supports a strict FIFO routing mode for organizations that require it; contact your Pipe17 representative if you have this requirement.


Setting an order's priority

There is no setting to turn this feature on. As soon as any of your orders carry a priority, processing honors it; if none do, behavior is unchanged.

Priority is set on the order programmatically — via the API, an automation rule, or ingestion mapping. The app displays each record's priority but does not edit it.

Via the API

Set priority when creating or updating an order. The accepted values are lowercase, and regular corresponds to the Standard label shown in the app:

{
  "priority": "high"
}

Valid values are "high", "regular", and "low". Any other value is rejected.

You can also filter list queries by priority — for example, priority=high on the orders list endpoint. The same filter is available on the shipping request and fulfillment list endpoints. Filtering by priority=regular returns Standard records and records with no priority set, matching how they are processed.

Shipping requests and fulfillments accept priority when they are created, but not on update. In normal operation you don't set it on them at all — they inherit it from the order.

Via automations

Use an automation rule in Automation Engine on the new-order or order-update trigger to set priority based on order attributes — for example, set High when the shipping service level is overnight, or when the order comes from a key account.

Via ingestion mapping

Where supported, connector mappings can populate priority from a field on the source system — for example, mapping an order tag or a shipping service level from your selling channel onto the priority field. Contact your Pipe17 representative to set this up for your connectors.


Viewing priority in the app

  • Order list pages: a Priority column shows each order's priority badge, and a Priority quick filter narrows the list to a level — for example, all High-priority orders at a glance.
  • Order, shipping request, and fulfillment detail pages: display the record's priority badge, including the value inherited from the order.
  • Standard shows no badge. Only High and Low orders display a priority badge; the absence of a badge means Standard. This includes orders with no priority set — they appear without a badge and are included when you filter by Standard.

Priority flows downstream

You set priority once, on the order. From there:

  • When a shipping request is created from the order, it inherits the order's priority.
  • When a fulfillment is created from that shipping request, it inherits the shipping request's priority.

Inheritance happens when the downstream record is created, and only if that record doesn't already have a priority of its own. Changing an order's priority later does not update shipping requests or fulfillments that already exist. To make priority flow all the way through, set it when the order is created — via the API, an automation, or ingestion mapping — before routing runs.


Where priority applies

Area What it does with priority Status
Order routing Routes High orders first in every run Available
Routing retries Retries out-of-stock, stuck, and failed orders High first Available
Automations Evaluates High orders first on new-order and order-update triggers Available
Connectors Pushes High-priority records to 3PLs and selling channels first Planned

Automation triggers other than new-order and order-update (for example, shipment-, fulfillment-, or exception-based triggers) do not use priority in this release.

Connectors currently push records in their existing order regardless of priority. Connector support — starting with Logiwa IO shipping request pushes and Shopify fulfillment status pushes — is planned; until it ships, priority accelerates an order through routing and automations but not through the connector push itself.


Common use cases

  • Expedited orders: map expedited or overnight shipping service levels to High so those orders route first.
  • B2B before D2C: mark wholesale orders High so they are processed ahead of direct-to-consumer volume, or mark D2C orders Low during a B2B crunch.
  • VIP customers: set High on orders from key accounts via automation or ingestion mapping.
  • Backfills and bulk imports: mark imported historical or test orders Low so they never delay live customer orders.

Best practices

  • Set priority at order creation, before the first routing cycle, so it reaches every downstream record.
  • Reserve High for orders that genuinely need it. If most orders are High, the passes stop meaning anything and you are back to age-based ordering — with extra Low-order delay.
  • Monitor Low orders during peak volume. If Low orders are aging past your service targets, raise their priority; a promoted order joins its new pass in the next cycle.
  • Don't rely on a manual routing rerun to jump the queue across priority levels. A manual rerun moves an order to the front of its own priority pass, but a Low-priority order still waits for the High and Standard passes to finish. To process a Low order immediately, raise its priority first, then rerun.

Troubleshooting

  • I filtered by Standard and see orders with no priority badge.
    This is by design. Standard is the absence of a priority: Standard orders and orders with no priority set show no badge, and both are included in the Standard filter. Only High and Low orders display a badge.
  • A Low-priority order hasn't routed for hours.
    Sustained High and Standard volume can defer the Low pass across many cycles. The order is not lost — it is processed when capacity frees up. If it needs to move now, change its priority to Standard or High.
  • I set priority on an order, but its shipping request doesn't show it.
    Priority is copied when the shipping request is created. If the order was routed before you set the priority, the existing shipping request keeps the value it was created with.
  • I manually reran routing on a Low order and it still didn't route right away.
    A manual rerun prioritizes the order within its own priority pass, not across passes. Raise the order's priority, then rerun.

Need Help?

If you need additional assistance:

  • Use Ask Pippen, our AI agent, located at the top of the app page.
  • Submit a support request with as much relevant detail as possible. Learn how to submit a request.

We're here to help you succeed with your operations.

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.

Have more questions?
Submit a request
Share it, if you like it.