A mobile sales order becomes useful when the office can act on the same customer, products, quantities, prices and delivery expectations that the representative discussed. Design the workflow around those decisions and their confirmation. Wireless access helps move the record, while the sales and fulfilment systems determine what it means.
This guide is for sales operations teams evaluating a field ordering process. Use an authorized test environment, test customers and products, and an agreed owner for pricing, inventory and fulfilment. Have the exact mobile app, CRM/ERP integration and supported offline behavior documented.
Define the states before testing the app
On a narrow screen, scroll the table sideways. Keyboard: focus the table and use the arrow keys.
| Stage | Evidence the representative needs | Next owner or decision |
|---|---|---|
| Customer and destination | Correct account, delivery address and buying contact | Sales owner resolves account ambiguity |
| Product selection | Product identifier, unit and quantity | Catalog owner resolves substitutes or pack sizes |
| Commercial terms | Currency, applicable price list, discounts and approval state | Pricing owner approves exceptions |
| Availability | Stock source, timestamp and reservation status | Fulfilment confirms what can be promised |
| Submission | Local reference, server order identifier and accepted lines | Integration owner resolves failures |
| Confirmation and amendment | Agreed delivery expectations and current order version | Order desk handles supported changes |
Give each displayed status a written definition. “Saved on phone,” “received by server,” “approved,” and “allocated” can represent different milestones. Ask the supplier which system supplies each state and how the app reports a rejected line or a delayed integration.
Microsoft's Dynamics 365 Sales order documentation provides a concrete example: orders can originate from quotes, and price-list, currency and price-lock behavior depend on configuration and integration. The document also identifies limits on changing closed or fulfilled orders. Use your actual workflow's rules when specifying acceptance; a familiar button label is insufficient evidence.
Keep prices and stock tied to their source
Before the visit, synchronize the data the app supports and inspect its last-update state. Establish what remains available offline: customer records, product details, prices, stock figures, order creation and approvals can have different support boundaries.
Record the price-list version or effective date and the unit of sale. A box of twelve and twelve individual items need distinct interpretation even when their displayed product names look similar. Test discounts and rounding against the organization's approved calculation rules.
Show the age and meaning of stock information. A quantity retrieved earlier is a snapshot. Ask whether the system reserves stock, when that reservation occurs, and what happens when another channel sells the same items. Give the representative wording that accurately communicates a requested quantity versus a confirmed allocation.
Walk one order through an exception
In a fictional test, a representative requests twelve cases using a stock snapshot that showed twenty at 09:00. At 10:15, the fulfilment system accepts only eight for the requested date. The app should make the four-case exception visible and preserve the customer's choice: accept a partial delivery, choose an approved substitute, change the date or cancel under the business's rules.
Verify the resulting line quantities in the office system and the customer confirmation. Record who approved the change. If the phone loses connectivity after submission, search by its stable reference before retrying. Test that the supported retry process produces the intended single order, with a clear result for every line.
Use the field-order acceptance record to capture these states. The Offline Mobile Work guide explains general pending uploads, conflicts and recovery; apply those concepts to the specific order states here.
Accept the workflow across the handoff
Run the same planned cases with the real device models and representative permissions: a normal order, stale stock, an unauthorized discount, a changed address, connection loss around submission, and a supported amendment. Include recovery after a closed app and a return to connectivity. Avoid real stock reservations, shipments or customer messages during testing.
For each case, compare the phone, CRM, ERP or fulfilment system, and confirmation record. Capture timestamps, identifiers, accepted and rejected lines, and the exception owner. Test users should be able to tell when to wait, correct an input, retry through the approved control or contact the order desk.
Agree release criteria before the pilot. An example is that every submitted test reference has one explainable final result, every price exception follows the approval rule, and every changed quantity is visible before confirmation. Treat unresolved discrepancies as work to finish before rollout. Retain the configuration, test evidence and support route so the same checks can be repeated after an integration or catalog change.