How to add a mobile app to ECI M1
Short answer
Build a mobile or tablet front end that talks to a thin service layer in front of M1, rather than to the database directly. Start with scanning and labor reporting, queue transactions for offline use, and post them through a supported M1 path with validation.
M1 is a Windows desktop-centric ERP, and on many shop floors that means people walk to a terminal to report time, move material or check a job. The data is entered late or in batches, so inventory and job costs trail reality, and supervisors approve things from a desk instead of from the floor.
A mobile app moves those few high-frequency actions to where the work happens. The value is not a copy of M1 on a phone but a handful of purpose-built screens: scan a job traveler, start and stop an operation, move a lot, receive against a PO. Keep the app small and the rules on the server.
What teams use it for
Labor reporting by scan
Scan a job traveler barcode to start or stop an operation, record quantity complete and scrap with a reason code.
Inventory move and cycle count
Scan location and part to move stock or count it, with variance flagged for approval before adjustment.
Receiving against POs
Look up an open PO, scan or enter quantities, capture a photo of the packing slip and post the receipt.
Job status and drawing viewer
Show current operation, next step, notes and the released drawing for the revision on the job.
Supervisor approvals on the floor
Approve scrap, rework or overtime requests from a tablet with the job context displayed.
ECI M1 integration surface
- SQL Server data behind M1 for jobs, operations, items, locations and POs, read through a service layer you own. Schemas vary by version.
- Supported M1 transaction entry interfaces in your release for labor, inventory and receiving; confirm with ECI which are available and licensed.
- Existing M1 shop floor or data collection modules and their barcode formats, which you may be able to extend rather than replace.
- Barcode and label printing from M1 jobs and travelers, which define the identifiers the app will scan.
- M1 user, department and work center setup, used for permissions and for filtering which jobs appear on a device.
How it works
- 1
Pick the first three transactions
Choose high-volume, low-risk actions such as labor start and stop, inventory move and receiving. Add more only after these are stable.
- 2
Build a service layer
Expose a small authenticated API in front of M1 for lookups and transactions. The app never connects to SQL Server directly.
- 3
Choose the client
Use a progressive web app for simplicity, or a native or cross-platform app if you need rugged scanner hardware integration and background sync.
- 4
Design for offline
Cache reference data, queue transactions on the device with timestamps and unique IDs, and sync when the network returns, with conflict rules.
- 5
Validate server-side
Check job is open, operation is valid, quantity is plausible and the user is allowed, before posting through the supported M1 path.
- 6
Pilot on one cell
Run alongside existing entry for a few weeks, reconcile differences and then expand.
Example flows
Operation start and stop
Trigger: An operator begins work on a job.
- Operator signs in with badge or PIN and scans the traveler.
- App shows the operation and checks it is the next valid step.
- Start is recorded; on stop the operator enters quantity and scrap.
- Service validates and posts the labor transaction to M1.
Result: Job costs and progress update during the shift instead of the next morning.
Offline cycle count
Trigger: A counter works in a metal-clad warehouse with weak Wi-Fi.
- Locations and expected quantities are cached on the device.
- Counts are scanned and stored locally with timestamps.
- Device syncs at the dock where signal is good.
- Variances above a threshold go to a supervisor before adjustment.
Result: Counts proceed without dead zones, and large adjustments are reviewed.
Keeping data on-prem
Host the service layer on your network beside M1, and expose it to devices through your internal Wi-Fi or a VPN, so nothing leaves the site. A progressive web app served from an internal server needs no app store, and managed devices can be locked to it. If you want remote access for field service staff, put the service behind a reverse proxy with mutual TLS or a zero-trust gateway rather than opening the database or M1 servers to the internet.
Security checklist
- Authenticate users by badge, PIN or single sign-on and map each to an M1 user and role.
- Never ship database credentials to a device; devices talk only to the service layer.
- Encrypt local offline storage and wipe it on logout or device loss.
- Give every queued transaction a unique ID so retries cannot double-post.
- Manage devices with MDM so lost scanners can be locked remotely.
Ways to get it done
Vendor or reseller shop floor and mobile modules
Effort: Licensing plus a few weeks of setup
Best first stop; ask what ECI and its resellers offer for your M1 version before building.
Build in-house with a PWA or cross-platform app
Effort: Two to four months for a solid first release
Good for a narrow set of transactions when you have developers and test devices.
Partner build with Netray
Effort: Scoped per workflow, usually a phased delivery
Suits teams wanting a custom floor workflow, offline sync and an optional private assistant in the app.
Pitfalls
- !Writing to M1 tables directly from the app service and bypassing business rules and costing logic.
- !Ignoring offline behavior until the first dead zone breaks adoption.
- !Building too many screens at once instead of perfecting scanning and labor first.
- !Barcode formats that differ between travelers, labels and bins.
- !No reconciliation period, so mismatches with desktop entry go unnoticed.
Frequently asked questions
Does ECI M1 have a mobile app?
Availability depends on your version and licensed modules, and resellers sometimes provide their own. Ask ECI or your reseller first. If nothing fits your workflow, a custom app over a service layer is the usual alternative.
Can a mobile app update inventory in real time?
Yes, if transactions are posted through a supported path as they happen. With offline mode they post when the device syncs, so design for short delays and duplicate protection.
PWA or native app?
A progressive web app is cheaper and easier to deploy on managed tablets. Choose native when you need deep scanner hardware support, background sync or strict offline behavior.
What hardware works best?
Rugged Android scanners and tablets with built-in imagers are common on shop floors. Choose based on the barcode types you print and the drop and dust conditions, then test with real labels.
Can we add AI to the mobile app?
Yes, for example a voice or text question about a job or part answered from M1 data. For sensitive shops, run the model on your own servers so floor queries and job data stay inside your network.
Want Mobile app working on your ECI M1?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment