Why the app should not talk to your systems directly
It is tempting to let a mobile app call the ERP or the database directly. It looks simpler, with one less thing to build. In practice it creates problems that are hard to undo. Anything stored inside an app can be extracted by a determined person, so credentials for an internal system do not belong there. Internal systems are rarely designed to face the internet. And a phone on a weak connection needs small, quick answers, where business systems tend to give large, slow ones.
The usual design places a service of your own between the two, often called a backend or an integration layer. The app talks only to that service. The service talks to the internal systems, on the app's behalf.
- It keeps secrets. Credentials for the ERP live on a server you control, never on a phone.
- It checks every request. The layer confirms who the user is and what they may see before anything is fetched.
- It shapes data for mobile. One request from the app can gather what a screen needs from several systems and return only that.
- It absorbs change. When an internal system is upgraded or replaced, the layer is adjusted and the app carries on.
- It protects the internal system. Caching and queues keep thousands of phones from hammering software built for a few dozen office users.
Find out how each system can be reached
This is the first technical question, and it should be answered before the app is designed. The answer for each system sets the cost, the speed and sometimes the feasibility of a feature.
| Way in | What it means | Consider |
|---|---|---|
| Documented interface | The vendor provides an API for reading and writing | Check that your edition and licence include it, and what limits apply |
| Vendor connector or middleware | A supported product that exposes the system | Extra licence cost, and a dependency on that product |
| Scheduled files | The system exports and imports files on a timetable | Data is only as fresh as the last run |
| Reading the database | Queries against the system's own tables | May breach support terms. Writing this way risks corrupting data |
| No interface | Only the screens exist | Automation of screens is fragile. Treat it as a last resort and a reason to plan a replacement |
Some vendors license access by outside applications separately from named users. Before designing a feature that lets many app users reach an ERP, read the licence terms or ask the vendor in writing.
Questions to answer for each connection
- 01
What exactly must the app read, and what must it write?
Why it mattersReading is far safer than writing. Each write needs rules, validation and a plan for failure.
- 02
Which system is right when two disagree?
Why it mattersA customer's address may exist in the CRM, the ERP and the app. One of them must win.
- 03
How fresh must each item be?
Why it mattersA stock figure may need to be current. A product description can be hours old and served from a cache.
- 04
How many requests will there be at the busiest moment?
Why it mattersInternal systems have limits. The layer must stay within them.
- 05
Is there a test environment?
Why it mattersWithout one, integration is developed against live data, which is slow and risky.
- 06
Who is the contact for this system?
Why it mattersA named person on your side, or at the vendor, who can answer questions and grant access.
Our integration discovery questionnaire gathers these answers for each system on one page.
Decide who the app user is to your systems
Inside an ERP, permissions belong to ERP users. App users are someone else: customers, drivers, technicians, sales staff. The connection needs a rule that links the two.
- 01
Staff apps
Sign staff in with the identity they already use at work, so that leaving the company removes app access too. Map each role to what it may see and do.
- 02
Customer apps
Customers have accounts in the app's own service, each linked to a customer record in the CRM or ERP. The layer enforces that a customer only ever receives their own data.
- 03
Actions in internal systems
Decide whether a change made in the app is recorded under the person's own internal user, or under one service user with the person's name noted. Auditors may care which.
- 04
Lost devices and leavers
Access should be revocable from the server at once, without waiting for the app to be updated.
Plan for old app versions and system upgrades
A website changes for everyone the moment it is deployed. An app does not. People keep old versions for months, and those versions go on calling your service in the old way. Meanwhile the internal systems are upgraded on their own schedule.
A connection built to last
- The service keeps older request formats working for a stated period
- The app can be told that an update is required
- Changes to internal systems are tested against the layer before going live
- Field names and codes from the ERP are translated in the layer, not in the app
- Someone is told when the ERP vendor announces a change
A fragile one
- Any change to the service breaks every installed app
- ERP field codes are hard-wired into app screens
- No way to retire a dangerous old version
- Upgrades to the ERP are discovered by app users
- Nobody owns the integration after launch
A worked example
A delivery app for a building materials supplier
This example is invented to show the questions being answered. A supplier wants drivers to see their deliveries, capture proof of delivery and record returns, all of which live in its ERP.
- Reaching the ERPThe ERP has a documented interface, included in the supplier's edition, with a limit on requests per minute. A test environment exists.
- LayerA small service is built. Each morning it loads the day's deliveries per driver from the ERP and holds them, so that 60 phones refreshing do not each call the ERP.
- WritesProof of delivery is sent to the service, which stores the signature and photo and then updates the delivery status in the ERP. If the ERP is unreachable, the update waits in a queue.
- IdentityDrivers sign in with their company accounts. All ERP updates are made by one service user, with the driver's name written to a note field, which the finance team accepts.
- ChangeWhen the ERP is upgraded, one field is renamed. The service is adjusted in an afternoon and no app update is needed.
Drivers never notice the ERP. The office sees delivery status update within moments, and the ERP is called a few hundred times a day instead of many thousands.
Design for a slow or unavailable system
Internal systems have maintenance windows, slow reports and bad days. An app used by customers or field staff cannot simply stop when they do. Decide, for each feature, what the app shows and does in that case.
| Situation | Poor behaviour | Better behaviour |
|---|---|---|
| System is slow | The screen spins until the user gives up | Show cached data marked with its time, and refresh in the background |
| System is down | A technical error message | Say plainly that live information is unavailable, and let the user continue where possible |
| A write fails | The user's work is lost | Keep it, queue it, retry it and show its status |
| A write is sent twice | A duplicate order or record | Give each action an identifier so the second attempt is recognized |
| Data looks wrong | The app shows it anyway | Validate in the layer and flag the record for a person |
Integration checklist for a mobile app
Mobile app integration checklist
0 of 11 checkedWhat to do next
Ask whoever looks after each internal system one question this week: how can another application read from it and write to it, and is that included in what we pay for? The answers will shape the scope of the app more than any design decision.
We build these layers as part of system integration and API development work. Tell us which systems are involved and we will say what we would check first.
Common questions
Can the app connect directly to our database?
It should not. A database password inside an app can be extracted, the database would have to be reachable from the internet, and any change to its structure would break every installed copy of the app. A service between the two solves all three problems and is standard practice for apps that handle business data.
What if our system has no API?
There are usually other routes: a connector sold by the vendor, scheduled file exchange or, with care, read-only access to its data. Each has limits on freshness and reliability. If the system offers none of these, features that depend on it may have to wait, and the finding is useful evidence when you plan that system's replacement.
Will connecting to our ERP make the app slow?
Not if the layer is designed for it. Data that changes rarely is cached. Screens are served from the layer's own store and refreshed in the background. Only actions that truly need a live answer, such as checking stock before confirming an order, wait for the ERP, and those are designed with a clear waiting state.
Who maintains the connection when our ERP is upgraded?
Someone must be named, because upgrades are the most common cause of integration failures. Typically the company that built the layer maintains it under a support agreement, and your ERP administrator warns them of planned changes. Testing the layer against the upgraded system in a test environment before go-live should be a fixed step.
Do we need our own backend if the ERP already has an API?
Almost always, yes. The ERP's interface was designed for trusted systems, not for thousands of phones. Your own layer handles sign-in, permissions, caching, notifications and the translation between ERP records and app screens. It can be small. What matters is that the app depends on a service you control.
