How to add a mobile app to DELMIAworks (IQMS)
Short answer
Add a mobile app to DELMIAworks by choosing between the vendor's own mobile or web options, a rugged-device scanning client, or a custom app over the REST API. Keep transactions small and validated server-side, and plan for patchy Wi-Fi with queued writes.
DELMIAworks grew from a Windows client built on Oracle, and shop floors that run it often still depend on fixed terminals, paper travelers and shared PCs. Operators walk to a terminal to report production, material handlers keyboard transfers, and supervisors approve on a desktop.
A mobile app solves the walking and the re-keying, but the ERP's data model is rich and some transactions are not appropriate for a phone. The design question is which few transactions to expose and how to keep them safe.
This page covers the realistic options, the integration surface, and what changes when the plant has dead zones, gloves and a mix of rugged scanners and personal phones.
What teams use it for
Production and scrap reporting
Scan a job traveler, enter good and scrap quantities with reason codes, and submit against the operation, with validation that the job is released and open.
Inventory moves and cycle counts
Scan from-location, item or lot, and to-location, with the app checking on-hand and lot status before posting a transfer.
Receiving against PO
Scan the PO barcode, confirm counts by line, capture lot and heat data, and print labels from the dock.
Labor and clock-in to job
Operators scan badge and job to log time, replacing batch entry by a supervisor at end of shift.
Maintenance requests and PM completion
Report a machine fault with a photo, or complete a PM checklist at the machine, linked to the equipment record.
Mobile approvals for supervisors
Approve overtime, scrap above a threshold or a requisition from a phone with the context shown.
DELMIAworks (IQMS) integration surface
- Vendor-provided mobile or web shop floor options (names and coverage vary by version and license); confirm what you already own before building.
- The REST API, where licensed, for job, inventory, receiving and labor transactions with authentication tokens.
- Oracle read-only views for lookups such as locations, items, open jobs and POs; writes should not use direct SQL.
- Real-time shop floor and machine monitoring components (names vary by version) that collect cycle and downtime data and may overlap with what a mobile app would capture.
- Barcode and label printing features in the ERP, which define the formats your scanning app has to read.
How it works
- 1
Inventory what you already own
List the vendor mobile, web and shop floor modules licensed. Many gaps can be closed by turning on what exists.
- 2
Pick the transactions
Choose three to five high-frequency ones: production report, inventory move, receiving, labor. Defer anything with complex rules.
- 3
Choose the client
A progressive web app works on any phone; a native app suits rugged scanner hardware with hardware triggers and better offline storage.
- 4
Build a thin backend
A small service validates input, calls the API, translates errors into plain language, and logs. Do not put ERP credentials on devices.
- 5
Handle offline
Queue transactions locally with an id, replay when connected, and make the backend idempotent so a retry does not double-post.
- 6
Pilot on one line
Run it beside the existing terminal for a couple of weeks, compare totals daily, and fix the friction before rolling out.
Example flows
Scan to report production
Trigger: An operator finishes a run on a press or machining center.
- Operator scans the job traveler barcode.
- App shows job, operation and remaining quantity.
- Operator enters good and scrap counts with a reason code.
- Backend validates and posts through the API.
- Confirmation shows the updated quantity complete.
Result: Production is reported at the machine, so the schedule reflects reality within minutes.
Offline transfer in a dead zone
Trigger: A handler moves pallets in a far warehouse bay with weak Wi-Fi.
- App scans lot and destination and stores the move locally.
- Handler continues to the next move.
- On reconnect, queued moves are replayed with their ids.
- Rejected moves, such as a lot placed on hold, are shown for correction.
Result: Work does not stop for connectivity, and errors surface with context instead of silently failing.
Keeping data on-prem
On-prem DELMIAworks usually means the app talks to the ERP over the plant LAN or a VPN, which is a strength: no data leaves the building. Host the backend inside the network, issue device certificates or use MDM-managed devices, and keep API credentials on the server. For remote users, use a reverse proxy with strong authentication in a DMZ rather than exposing the ERP. If you add voice or photo features, such as describing a defect, process them with local models so images of parts and customer drawings stay on your servers. Plan Wi-Fi coverage and handheld hardware before software, since many mobile rollouts fail on coverage, not code.
Security checklist
- Authenticate users with SSO or badge plus PIN, and map to ERP roles with least privilege.
- Keep API credentials server-side; devices hold only short-lived session tokens.
- Enforce MDM on devices, with remote wipe for lost scanners and phones.
- Make every write idempotent and logged with user, device and timestamp.
- Restrict approvals and cost visibility to authorised roles.
Ways to get it done
Vendor mobile or shop floor modules
Effort: Configuration and training, days to weeks.
First choice if licensed; lowest maintenance and supported through upgrades.
Third-party scanning or WMS client
Effort: Several weeks including label and device setup.
Good for warehouse-heavy flows if it supports your version's API or import paths.
Custom app or partner build with Netray
Effort: Pilot of two or three transactions, then expand.
When your flow is unusual or you want AI assist, such as defect description or ask-the-ERP, on-prem.
Pitfalls
- !Replicating the whole desktop client on a phone instead of a few focused transactions.
- !Ignoring Wi-Fi dead zones until go-live.
- !Posting non-idempotent writes, so a retry double-counts production.
- !Letting devices hold ERP credentials.
- !Skipping operator feedback; gloves and glare change what a usable screen looks like.
Frequently asked questions
Does DELMIAworks have its own mobile app?
The vendor offers mobile and web options that vary by version and license, so confirm with your reseller what you own. Gaps are typically filled with a scanning client or a custom app over the API.
Native app or progressive web app?
A PWA is faster to build and works across devices. Native is better for rugged scanners with hardware triggers and deeper offline storage. Many plants use a PWA first and go native only if needed.
Can it work offline?
Yes for queued transactions, with idempotent replay. Lookups need cached data, and some validations must wait until you are connected.
How do we avoid direct database writes?
Use the REST API or supported import paths for writes and keep Oracle access read-only. That preserves ERP validation, audit and upgrade safety.
What does a pilot cost in time?
A focused pilot of two or three transactions on one line is typically a matter of weeks, with most of the time spent on devices, labels and operator feedback.
More for DELMIAworks (IQMS)
Want Mobile app working on your DELMIAworks (IQMS)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment