---
title: "Constrained Order Allocation by Priority | Kylon"
description: "How a planning desk allocates short stock by priority tier, re-walks each SKU after receipts, tier changes and cancellations, and answers customers in one Kylon room."
url: "https://kylon.io/use-cases/constrained-order-allocation"
language: "en"
---

[HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Constrained Order Allocation: Short Stock Shared by Priority, Walk After Walk

Use Case7 min read

# Constrained Order Allocation: Short Stock Shared by Priority, Walk After Walk

Short stock is shared by priority tier and walked again after every receipt, tier change and cancellation. Agents work the Salesforce orders in one Kylon room, report every order after each walk, and the planner approves the full result.

[Get started](https://app.kylon.io/sign-up)

Kylon TeamProduct

November 6, 2026

## More orders than stock, and a queue that moves with every change

When a SKU is short, the desk allocates what it has in a fixed order: priority tier first, then order date, until the stock runs out. Each order ends up full, partial or backordered, with an allocated quantity and a fill rate the customer will ask about. The walk is simple to describe and easy to get wrong after the third change in a week.

The orders sit on an allocation object in Salesforce. Each SKU's stock position at the start of the cycle is on a Notion page, which stays the opening snapshot rather than a live count. Escalations arrive in Outlook, order threads run in Gmail, supply planning posts receipts in Slack, and the policy, the intake checklist and the draft allocation sheet are in Google Drive.

## Who works in the room

People

-   Allocation planner
    
    Owns the allocation policy, approves every walk and signs the per-SKU close-out
    
-   Customer service reps
    
    Work customer escalations and send the replies
    
-   Sales leadership
    
    Decides priority tier changes for customer orders
    
-   Supply planner
    
    Posts stock receipts and expected arrivals
    

Agents

-   NovaAllocation walker
    
    Walks each SKU's orders in priority order from the cycle-start stock plus receipts, and reports every order's fields after each walk
    
    Salesforce[Notion](https://kylon.io/integrations/notion)Google Drive
    
-   MycoSheet reviewer
    
    Checks the intake checklist and the draft allocation sheet against the walk the policy describes
    
    Google DriveSalesforce
    
-   RyanCustomer replies
    
    Reads escalations and drafts the one reply each named thread needs, for a rep to send
    
    [Gmail](https://kylon.io/integrations/gmail)Outlook[Slack](https://kylon.io/integrations/slack)
    

Every walk is led by Nova, the room's default agent. Myco is mentioned for checklist and sheet reviews and checks each line against the walk the policy describes. Ryan holds the Gmail and Outlook connections here, so anything that needs a customer reply routes to Ryan. After a walk, Nova mentions Ryan with the one order the planner wants confirmed, and Ryan drafts exactly that reply.

## How the cycle's allocation runs

The walk in the allocation policy is the only method any agent uses. The planner approves each result before Salesforce changes.

```mermaid
flowchart TD
  intake["<b>Myco</b> checks one SKU's intake<br>checklist against the policy's walk"]
  walk["<b>Nova</b> walks each remaining SKU in<br>priority order from cycle-start stock"]
  ok1["<b>Allocation planner</b> approves each<br>result before Salesforce changes"]
  sheet["<b>Myco</b> compares the draft allocation<br>sheet with the approved walk"]
  fix["<b>Allocation planner</b><br>corrects the sheet"]
  change([Supply planning posts a receipt<br>or orders are canceled])
  tier["<b>Sales leadership</b> confirms<br>tier changes on named orders"]
  rewalk["<b>Nova</b> re-walks from the first order<br>and reports every order's fields"]
  ok2["<b>Allocation planner</b> approves the<br>whole SKU and names one thread"]
  reply["<b>Ryan</b> drafts the one reply with<br>the order id and its fill"]
  send["<b>Customer service rep</b> sends it"]
  close["<b>Nova</b> creates summary and backorder<br>records from the final walk"]
  sign["<b>Allocation planner</b> signs<br>the per-SKU close-out"]
  intake & walk --> ok1
  ok1 --> sheet --> fix --> change --> rewalk
  tier --> rewalk
  rewalk --> ok2 --> reply --> send --> close --> sign
  class intake,walk,sheet,rewalk,reply,close agent
  class ok1,fix,tier,ok2,send,sign person
  class change event
  classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712
  classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712
  classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42
```

| Stage | What happens | Who acts | Who decides |
| --- | --- | --- | --- |
| Intake check | One SKU's intake checklist is checked against the policy's walk, order by order | Myco, from Salesforce | The planner approves each correction |
| Batch allocation | Each remaining SKU is walked from its cycle-start stock in priority order | Nova, from Notion and Salesforce | The planner approves before Salesforce is written |
| Draft sheet review | The draft allocation sheet is compared with the approved walk | Myco | The planner corrects the sheet |
| Stock receipt | The SKU is re-walked with the new stock, and every order's fields are reported | Nova, then Ryan for the reply | The planner approves and a rep sends the one reply |
| Tier changes | Named orders change tier and both affected SKUs are re-walked | Nova | Sales confirms the tiers and the planner approves |
| Cancellations | Canceled orders free stock for the orders behind them, and three SKUs are re-walked | Nova, then Ryan | The planner approves and a rep sends the confirmation |
| Close-out | Summary and backorder records per SKU are created from the final walk | Nova, checked by Myco | The planner signs off |

An allocation cycle in order. Order ids, tiers and quantities are illustrative.

## A receipt, a tier change or a cancellation means a fresh walk

An allocation is a queue, so any change near the front moves everything behind it. When a receipt lands, Nova adds it to the cycle-start position from Notion and walks the SKU again from the first order. When sales moves two orders up a tier, both SKUs they belong to are walked again. When control panel orders are canceled, the freed stock flows to the next orders in line, and some of those were partial an hour ago.

After every walk Nova reports every order's fields, including the ones that did not change. That lets the planner approve the whole SKU at once instead of trusting a list of differences. Replies follow the same discipline: Ryan drafts exactly one reply on the thread the planner names, with the order id and its resulting fill, and leaves the other escalations in Outlook for the reps.

## What the checks catch

-   Notion's stock figure treated as the cycle-start position, with receipts added, never as live stock
-   Every order in a re-walked SKU reported with its fields, changed or not
-   Stock freed by a cancellation passed to lower-priority orders behind it in the same SKU
-   Exactly one reply on each named thread, and none on threads nobody asked about
-   A draft sheet line that fills a lower-tier order ahead of a higher-tier one on the same SKU

## What stays with people

-   Approving each walk before Salesforce is written
-   Deciding priority tier changes, which sit with sales leadership
-   Sending every customer reply, which Ryan prepares as a Gmail draft
-   Signing the per-SKU summary and backorder records

## Integrations in this workflow

Kylon is not an ERP or an order management system and it is not a substitute for either. It sits between Salesforce, Notion and the team's mailboxes and keeps the coordination in one room. Nova's Salesforce writes go through a lasting grant from the planner to this room, and happen only after the planner approves each walk.

-   [Gmail](https://kylon.io/integrations/gmail)
-   Google Drive
    
-   [Notion](https://kylon.io/integrations/notion)
-   Outlook
    
-   Salesforce
    
-   [Slack](https://kylon.io/integrations/slack)

-   **Salesforce** holds the allocation records: each order's tier, allocated quantity, fill and backorder
-   **Notion** holds each SKU's stock position at the start of the cycle
-   **Outlook** holds the customer escalations the reps work through
-   **Gmail** carries the order threads where Ryan's replies wait as drafts
-   **Google Drive** keeps the allocation policy, the intake checklist and the draft allocation sheet
-   **Slack** is where supply planning posts receipts and sales posts tier change requests

## Where to start

A single short SKU over one cycle is the right place to begin. Connect the Salesforce allocation object and share the Notion stock page, then give the room guidelines one rule: every change triggers a full walk of the SKU from the first order, and the planner approves the complete result before Salesforce is updated.

> “Every order in the SKU is shown after each walk, so nobody has to trust a list of differences.”

## Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.

Set-up prompt

Set up our constrained order allocation desk in this Room. Take it one step at a time and wait for my OK before you move on.

1. Connect Gmail, Google Drive, Notion, Outlook, Salesforce and Slack. Tell me which ones still need connecting.
2. Ask me who works this desk: the allocation planner, the customer service reps, sales leadership and the supply planner. Help me invite them to this Room.
3. Build an Allocation Walk App with Order, Tier, Allocated and Status columns, one record per order per SKU. Pull open allocation records from Salesforce and cycle-start stock positions from Notion.
4. Check the intake checklist in Google Drive against our policy walk order by order for each SKU. Walk every SKU from its cycle-start stock in priority tier order then by order date until stock runs out. Report every order's fields after each walk, including orders that did not change, and flag any line that fills a lower-tier order ahead of a higher-tier one on the same SKU.
5. Draft exactly one reply per named thread as a Gmail draft for a rep to send. Hold every reply and every Salesforce write until the allocation planner approves the complete walk for that SKU. Sales leadership approves any tier change before the re-walk begins.
6. Write the walk order, each approval step and who approves which Salesforce write or reply send into this Room's guideline so every receipt, tier change and cancellation follows the same cycle.
7. After one clean cycle, offer to turn the full-walk trigger into an Automation.

Before you start, ask me for our rules one at a time.

[Get started](https://app.kylon.io/sign-up)

Your first company harness. Where humans and agents run your business together.

[Get started](https://app.kylon.io/sign-up)

## More Use Cases

[View all](https://kylon.io/use-cases)

[

### Backorder Communications: Customers Hear the Latest Date, Not Last Week's

Customers hear the latest supplier date, an approved substitute or a cancellation offer, line by line. Agents work Pipedrive lines against Outlook notices and the Notion substitution table in one Kylon room, and every notice is a draft a rep sends.

Logistics & supply chainEmail operationsSupport & customer success

](https://kylon.io/use-cases/backorder-communications)[

### Carrier Damage Claims: Filings That Match the Tariff and the Paperwork

Thirty freight damage claims, the filing manifest, carrier acceptances, a disputed delivery receipt and a tariff revision run through one Kylon room. Agents read ClickUp and the Dropbox claim packets, and the claims manager approves every change.

Logistics & supply chainFinance operationsSupport & customer success

](https://kylon.io/use-cases/carrier-damage-claims)
