--- title: "Spare Parts Min and Reorder Planning | Kylon" description: "How a plant storeroom sets min and reorder levels, builds a PO run under budget and re-checks linked parts after every change in one Kylon room, with people approving." url: "https://kylon.io/use-cases/spare-parts-reorder-levels" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Spare Parts Reorder Levels: Stocking Rules That Hold When One Part Changes Use Case8 min read # Spare Parts Reorder Levels: Stocking Rules That Hold When One Part Changes When one part changes its lead time, criticality or supersession, every part tied to it is checked again. Agents set min and reorder levels from ClickUp work orders and Salesforce quotes in one Kylon room, and the planner approves each level. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Thirty part numbers, one budget and a history spread across work orders Setting reorder levels for a maintenance storeroom looks like arithmetic. Each part's min covers consumption during its lead time, its reorder point adds a buffer, and critical spares get more cover because a missing seal kit can stop a line for days. Some parts have been superseded by a new number, some are obsolete, and some are stocked at zero and bought only when a job needs them. The inputs never sit together. Consumption comes from maintenance work orders in ClickUp, lead times come from supplier quotes in Salesforce, the parts table lives in Airtable, and the stocking policy and the month's budget are documents in Google Drive. Changes arrive in Slack from reliability and maintenance. A change to one part usually affects others, and that is the step a busy planner skips. ## Who works in the room People - Inventory planner Owns the stocking policy, approves every level before it is written and confirms the final run - Buyer Drafts the PO sheet and places the purchase orders - Reliability engineer Sets part criticality and confirms supersessions - Maintenance manager Approves the monthly PO run against the spares budget Agents - FinStocking planner Sets min, reorder point and quantity for each part from consumption and lead time, builds the PO run, and re-checks every linked part after a change AirtableClickUpSalesforceGoogle Drive[Slack](https://kylon.io/integrations/slack) - NovaPO sheet checker Checks the buyer's draft PO sheet line by line against the approved run and lists every disagreement Google DriveAirtable The storeroom runs one room for planning. Fin is the default agent and owns the run, so a planner's message about a new quote or a criticality change goes to Fin without a mention. Nova works only on the buyer's sheet. When the buyer posts a new draft, Fin mentions Nova in the thread with the approved run attached, and Nova leads the review until the list of disagreements is back with the buyer. ## The monthly reorder run The rules are the same every month, and so is the order of the work. Nothing is written or ordered until a person approves it. ```mermaid flowchart TD levels["Fin sets each part's min, reorder
point and quantity, or a status"] ok1["Inventory planner approves
before Airtable is written"] run["Fin queues parts at their reorder
point, critical first, to budget"] okrun["Maintenance manager
approves the run"] sheet["Nova checks the buyer's draft
PO sheet against the run"] buyer["Buyer corrects the sheet"] change([A new lead time or a
criticality change arrives]) reversal([An engineer reverses
a supersession]) rerun["Fin re-runs the named part and
every part the policy ties to it"] revive["Fin returns the old part to active
and clears its successor link"] reliab["Reliability confirms criticality,
planner approves the levels"] recheck["Nova re-checks the PO run"] okrev["Inventory planner approves"] close["Fin checks final levels and the
PO run against the current table"] sign["Maintenance manager signs off"] levels --> ok1 --> run --> okrun --> sheet --> buyer buyer --> rerun & revive change -.- rerun reversal -.- revive rerun --> reliab --> close revive --> recheck --> okrev --> close close --> sign class levels,run,sheet,rerun,revive,recheck,close agent class ok1,okrun,buyer,reliab,okrev,sign person class change,reversal 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 | | --- | --- | --- | --- | | Reorder levels | Each part in the range gets a min, a reorder point and a quantity, or a status of superseded, obsolete or zero min | Fin, from ClickUp work orders and Salesforce quotes | The inventory planner approves before Airtable is written | | PO run | Parts at or below their reorder point are queued, critical first, until the month's budget is used | Fin | The maintenance manager approves the run | | Draft PO sheet review | The buyer's sheet is compared line by line with the approved run | Nova | The buyer corrects the sheet | | Lead time or criticality change | The named part and every part the policy ties to it are re-run | Fin | Reliability confirms criticality and the planner approves the levels | | Supersession reversal | The old part returns to active, its successor link is cleared and the PO run is re-checked | Fin, then Nova | The planner approves | | Close-out | Final levels and the PO run are confirmed from the current table | Fin, checked by Nova | The maintenance manager signs off | One month's run. Part numbers, levels and lead times are illustrative. ## One part changes, and the parts around it move too Most changes name a single part. A supplier quotes a longer lead time for a spindle bearing. Reliability marks a seal kit critical after a press stoppage. An engineer reverses a supersession because the new coupling does not fit the older drives. Fin treats the named part as the start of the re-check. A new critical part competes with every other critical part for the same budget, so all of them are re-run. A reversed supersession brings the old part back to active, clears its successor link, and may put it into this month's PO run. A consumption correction is the widest change. When maintenance finds that a set of work orders logged the wrong part number, usage moves from one part to another. Fin re-runs every affected part and re-confirms each part set aside as superseded, obsolete or zero min, because a corrected history can bring one of them back. Each changed row gets a short note saying which correction moved it. ## What the checks catch - A draft PO line with the wrong quantity, for a part not at its reorder point, outside this month's range, or listed twice - A part due for reorder that is missing from the draft PO sheet - Every part already critical re-run when another part joins the critical tier - A reversed supersession that leaves the successor link in place or skips the PO run - Superseded, obsolete and zero min parts re-confirmed after a consumption correction ## What stays with people - Approving levels and the PO run before Airtable changes - Placing purchase orders, which stays with the buyer - Deciding criticality, which stays with reliability engineering - Signing off the month's run against the spares budget ## Integrations in this workflow Kylon is not an inventory or maintenance management system, and it is not a replacement for either. It sits across the storeroom's tools and holds the coordination that usually lives in one planner's head. Fin reads ClickUp and Salesforce through a lasting grant the maintenance manager approved for this room, and writes to Airtable only after the planner approves. - Airtable - ClickUp - Google Drive - Salesforce - [Slack](https://kylon.io/integrations/slack) - **Airtable** holds the parts table: levels, status, supersession links and the PO run - **ClickUp** holds maintenance work orders, which give each part its consumption history - **Salesforce** holds supplier accounts and the quotes that carry each part's lead time - **Google Drive** keeps the stocking policy, the month's budget and the buyer's draft PO sheet - **Slack** is where reliability and maintenance post criticality and supersession changes ## Where to start Take one storeroom and one block of part numbers. Connect the Airtable parts table and the ClickUp work order list, schedule an automation that opens the run on the first Monday of the month, and write one rule in the room guidelines: when a part changes, Fin re-runs every part the policy ties to it, and the planner approves the whole list before Airtable changes. > “When one part changes, the list of parts that moved with it is already in the thread.” ## 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 spare parts reorder desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, ClickUp, Google Drive, Salesforce and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the inventory planner, the buyer, the reliability engineer and the maintenance manager. Help me invite them to this Room. 3. Build a Spares Planning App with Part, Min and reorder, Lead time and Status, one record per part. Fill it from the Airtable parts table and the ClickUp work order list. 4. Set a min, reorder point and quantity for each part using ClickUp consumption and Salesforce lead times. Mark superseded, obsolete and zero min parts. When one part changes, re-run every part our policy ties to it and show me the full list before anything is written. 5. Queue parts at or below their reorder point, critical first, within the threshold we set from Google Drive. The inventory planner approves every level before Airtable is written. The maintenance manager approves the PO run before any order is placed. 6. When the buyer posts a draft PO sheet in Google Drive, check it line by line against the approved run and list every disagreement back to the buyer. 7. Write our rule order and who approves what into this Room's guideline so every monthly run follows it. 8. After one clean run, offer to open the monthly run on the first Monday of the month as 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) [ ### Engineering Change Orders: Each Change Decided on Its Own Record, With Dates That Hold A weekly change board decides thirty change orders on their own records, with effective dates set from stock on hand and supplier commit dates. Agents prepare and check each one in a Kylon room, and the board chair approves every disposition. ManufacturingApprovals & reviews ](https://kylon.io/use-cases/engineering-change-orders)[ ### Equipment Calibration: Every Instrument Cleared or Quarantined on Its Own Record Each instrument gets its status from its own class, due date and certificate. Agents work Airtable, SharePoint and the lab mail in one Kylon room, plan outside lab visits and handle voided calibrations, and the quality manager approves every status. ManufacturingCompliance & riskScheduling & dispatch ](https://kylon.io/use-cases/equipment-calibration)