Order Desk

The Order Desk workflow is for customer intake work that already happens every day: reading a customer PO, matching the customer and items, checking Acumatica context, preparing reviewed sales order work, and keeping shipment actions separate until approved.

Business Problem

Order desk teams receive customer POs as emails, PDFs, screenshots, spreadsheets, forwarded notes, and attachments. Staff still have to identify the customer, map item numbers, check availability and pricing context, prepare the sales order, attach source documents, and coordinate shipment work.

The risk is practical: the work is repetitive, but a wrong customer, wrong item, wrong quantity, missing document, or premature shipment action creates cleanup across sales, warehouse, finance, and customer service.

Example Starting Prompt

Please read this customer PO email. Identify the customer, PO number, requested items, quantities, requested ship date, and shipping notes. Match the customer and items in Acumatica, check availability and pricing context, and prepare a sales order for review. Do not create the order until I approve it.

Complete Workflow

The workflow starts with the customer’s source request. That can be an email, PDF, screenshot, spreadsheet, forwarded note, or attachment. The source document should remain available for review because it becomes the evidence behind the extracted customer, PO number, requested ship date, requested items, quantities, units, and shipping notes.

The assistant extracts the order request into a reviewable structure. The user should see the original customer value beside the proposed Acumatica value: customer name, customer account, ship-to location, customer item number, Acumatica inventory item, unit of measure, quantity, requested date, requested carrier, and any special instructions.

Next, Acumatica MCP Tools validates the request against approved records. The workflow checks customer and ship-to context, inventory item matches, item status, availability, pricing context where exposed, open order context where useful, and any configured fulfillment or account indicators. If the customer, ship-to, item, quantity, unit, or requested date is ambiguous, the workflow pauses and asks for clarification instead of guessing.

Once the extracted request is clear, the workflow prepares a sales order review packet. The packet should include the proposed order header, proposed line items, matched records, unresolved exceptions, pricing or availability notes, and the exact source values used from the customer PO. This is the point where the order desk user decides whether the prepared order is correct.

Sales order creation happens only after the user approves it. The action also requires a sales order write allowlist and the current Acumatica user must have permission. If either control is missing, the workflow stops at the prepared order payload and explains what prevented creation.

After the order exists, the workflow can attach the source PO only when attachment tools are allowlisted for the Sales Order target record. Shipment preparation remains separate. The workflow can summarize next fulfillment steps, but shipment creation, shipment confirmation, allocation changes, or carrier updates require a separate approval path and separate allowlist review.

The final output should show the created or prepared sales order, source document attachment status, exceptions that remain open, and the audit-relevant operations that were allowed or denied.

Acumatica Records and Tools

• AI client for reading the customer source document and coordinating the workflow.
• Acumatica MCP Tools for customer, item, sales order, attachment, and shipment workflows.
• Contract REST API schema and read tools.
• Allowlisted contract REST API write and attachment tools for approved order work.
• Optional Entity OData v4 or Generic Inquiry OData reads for availability, order, or fulfillment views.

The common Acumatica records are Customer, customer location or ship-to context where exposed, Inventory Item, Sales Order, Shipment, pricing or availability views where exposed, and Attachments.

Human Approval Point

The user approves customer match, ship-to match, item match when ambiguous, quantity or date clarification, pricing exception review, sales order creation, source document attachment, and any shipment preparation or shipment creation.

The assistant should ask for clarification before guessing on ambiguous customer, ship-to, item, quantity, unit, or shipping data.

Guardrails to Show

Sales order creation, attachments, and shipment actions are separate controls. An unrelated destructive request remains denied even after the order workflow is enabled.

Recommended first controls are read-only customer and item validation, a narrow sales order write allowlist, a separate attachment allowlist for Sales Order, and no shipment action until the team explicitly approves that step.

Good First Setup

Start with one fake, sandbox, or approved customer PO with known customer and item records. Success means the workflow extracts the request accurately, validates customer and item context, identifies availability or pricing exceptions, prepares the reviewed order payload, creates the order only after approval if writes are allowlisted, attaches the source PO only if attachment tools are allowlisted, and stops before shipment actions unless a separate workflow is approved.

Review the audit output for the read calls, the approved write or attachment call, and at least one denied operation.

Related Reading

• Academy overview: Workflows
• Foundation: Read vs. Write Access
• Developer reference: Safety Model
• Developer reference: Tool Guide

Guided Deployment

Bring one real order desk workflow for guided deployment. We will map the customer request, Acumatica records, approval points, sales order allowlist, attachment allowlist, and any shipment action boundary.

Request Free Guided Deployment