How to build a mobile app for Dynamics NAV
Short answer
Build a mobile or handheld app that scans barcodes and calls NAV through published codeunits for receipts, picks, moves and production output, instead of writing to tables directly. Add local queuing for weak Wi-Fi, and use NAV's own journals and warehouse documents so costing and tracking stay correct.
Warehouse and shop-floor staff do not want the full NAV client on a handheld. They want to scan a bin, scan an item, enter a quantity and be done. Many NAV sites still rely on paper pick lists and keyboard entry at a desk.
NAV does offer tablet and phone clients and a web client, which can serve simple needs. Where barcode-driven workflows, rugged devices or custom screens are required, teams build a thin app over web services.
The rule that matters: call NAV's posting logic through codeunits so inventory, costing and item tracking behave exactly as they do from the client.
What teams use it for
Goods receipt against PO
Scan the PO and item, enter quantity received and lot, and post a Purchase Receipt or warehouse receipt line.
Directed picking
Show Warehouse Activity Lines for a pick, confirm bin and quantity by scan, and register the pick.
Inventory moves and transfers
Move stock between bins or locations using item journals or warehouse reclassification, with bin validation.
Production output and scrap
Report output and scrap on a released Production Order through a Consumption or Output journal with operation context.
Labor and job time
Start and stop time against production routing lines or jobs, feeding capacity ledger entries.
Cycle counting
Use a Physical Inventory Journal with scan-based counts and variance review before posting.
Microsoft Dynamics NAV integration surface
- Dynamics NAV tablet and phone clients and the web client can host simple pages, but custom scanning behavior usually needs a separate app.
- Published codeunits are the safest entry points for posting item journals, warehouse activities and production journals with the same code the client runs.
- Pages and queries published as OData or SOAP supply lookups: Item, Bin Content, Warehouse Activity Line and Production Order Line.
- Warehouse Management objects such as Warehouse Receipt, Warehouse Pick and Bin Content exist when the location is set up for directed put-away and pick; simpler locations use item journals.
- Item Tracking (serial and lot) is tracked through Tracking Specification and reservation entries, which mobile calls must populate before posting.
How it works
- 1
Define the workflows
Pick the top three: receive, pick, move. Specify each screen, the scan sequence and the NAV document it touches.
- 2
Choose the platform
Android handheld app, cross-platform framework or a progressive web app. Rugged Zebra or Honeywell devices with a scanner SDK are common.
- 3
Publish purpose-built codeunits
For each action expose a function with simple parameters and clear errors, wrapping the posting logic and validations.
- 4
Handle authentication
Use per-user credentials or a badge login mapped to NAV users so user IDs on entries are real. Avoid a shared device account.
- 5
Design for poor connectivity
Queue actions locally with idempotency keys, sync when online, and show clear status for pending items.
- 6
Add validation on the device
Check item, bin and quantity locally using cached lookups to give instant feedback, but keep NAV as the final authority.
- 7
Pilot on one zone
Launch in one area, compare transaction counts and error rates against the manual process, then expand.
Example flows
Receive against a PO
Trigger: A truck arrives with a delivery.
- Operator scans the PO barcode.
- App lists open lines from a published page.
- Operator scans the item and enters quantity and lot.
- The receipt codeunit posts the receiving line.
- A label is printed for put-away.
Result: Inventory is updated at the dock instead of hours later.
Report production output
Trigger: An operator completes a batch at a work center.
- Scan the production order and operation.
- Enter good and scrap quantities.
- App sends output through the journal codeunit.
- NAV updates capacity and item ledger entries.
Result: WIP and costs stay current.
Cycle count
Trigger: A scheduled count for aisle C.
- The app downloads a Physical Inventory Journal for the bins.
- The counter scans bins and items and enters counts.
- Variances over a tolerance are flagged.
- A supervisor approves before the journal posts.
Result: Accuracy improves without shutting the warehouse.
Keeping data on-prem
A shop-floor app fits on-prem well because the device only needs to reach your own network. Host the app backend on a server in the plant or DMZ, call NAV over the internal LAN, and keep Wi-Fi coverage and device management under IT control. If you must support remote sites, use a VPN or private link rather than exposing the NAV service tier. Add an on-device cache for items and bins, and plan for server downtime by letting the app queue transactions safely.
Security checklist
- Authenticate users individually and map to NAV users so ledger entries carry real user IDs.
- Lock devices with an MDM policy and disable screenshots and USB where appropriate.
- Use TLS for all traffic and certificate pinning on the app backend.
- Limit each codeunit to the minimum action and enforce permission sets in NAV.
- Make queued transactions idempotent to prevent duplicates after reconnection.
Ways to get it done
NAV tablet or phone client with custom pages
Effort: Days of page design.
Light needs, approvals and lookups without scanning.
Third-party warehouse or shop-floor mobile add-on
Effort: Weeks, with licensing and device costs.
Standard WMS flows with a vendor supporting your NAV version.
Custom app with Netray or in-house developers
Effort: 6 to 12 weeks for a first set of workflows.
Unique routings, traceability or industry-specific labeling.
Pitfalls
- !Writing to tables directly bypasses costing and tracking and corrupts inventory.
- !Shared logins hide who made a transaction.
- !Ignoring item tracking leads to posting failures at the dock.
- !Large Wi-Fi dead zones cause duplicate scans when the app retries without idempotency.
- !Replicating the full NAV screen on a small display instead of a task-focused flow.
Frequently asked questions
Does Dynamics NAV have a mobile app?
NAV has tablet and phone clients and a web client, which suit light use. For barcode-driven receiving, picking and production reporting on handhelds, most sites use a purpose-built app or a third-party add-on that calls NAV through web services.
Can the app work offline?
Yes, by caching lookups and queuing transactions locally, then syncing when connected. Each queued action needs an idempotency key so retries do not double post. Decide how long offline operation is acceptable for your process.
Which devices should we use?
Android rugged handhelds from vendors like Zebra or Honeywell are typical because of built-in scanners. Phones with camera scanning can work for low volume. Choose based on environment, scan speed and battery needs.
How do we keep costing correct?
Post through NAV codeunits that use the same logic as the client, such as item journals, warehouse activities and production journals. Never insert ledger entries directly in SQL.
Can we add AI features?
Yes. Examples include voice entry, photo capture of damage with a vision model, or a local assistant that explains a shortage. Keep models on-prem and treat suggestions as inputs a user confirms.
Want Mobile app working on your Microsoft Dynamics NAV?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment