Mobile integration guide
Connecting mobile apps to existing business systems
Connect the app through a controlled server-side boundary that translates mobile journeys into authorised business actions. Keep system credentials, record access and authoritative rules away from the device.
The short answer
A mobile app should normally connect to existing ERP, CRM, warehouse, finance or operational systems through a server-side API or integration layer. That boundary authenticates the person, authorises the exact record and action, validates input, translates between data models and records what happened.
The app should not hold privileged system credentials, query a production database directly or reproduce every internal data field. It needs a stable contract designed around the mobile user's task. The system of record can remain authoritative behind that contract.
01
Put a deliberate boundary between the device and internal systems
The boundary reduces coupling. A mobile release can evolve without mirroring an ERP screen, and an internal-system change can be absorbed by an adapter without forcing every installed app to change immediately.
| Responsibility | Mobile app | Server-side boundary | Business system |
|---|---|---|---|
| User experience | Task flow, device state and feedback | Channel-ready response model | Not responsible |
| Access decision | Presents allowed options | Enforces identity, role, record and action | May add system-specific controls |
| Business rules | Immediate guidance only | Coordinates authoritative rules | Owns rules tied to its records |
| Credentials | User token in protected storage | Privileged service credentials | Validates trusted caller |
02
Treat a native app as a public client
An installed application cannot safely keep a client secret because its package and runtime are ultimately on a user's device. Use an appropriate identity provider and short-lived, scoped tokens. For OAuth-based sign-in, RFC 8252 recommends the external user-agent pattern and requires PKCE for public native clients.
- authenticate the person through a trusted identity flow;
- authorise every protected record and action on the server;
- separate customer, employee, device and service identities;
- scope tokens to the minimum APIs and permissions required;
- store refresh credentials using platform-supported protected storage; and
- support session expiry, revocation, lost devices and role changes.
Hiding an action in the interface is not authorisation. The API must make the decision again from trusted identity and current business context.
03
Design the API around mobile outcomes
A useful contract is smaller and more stable than the underlying system schema. It returns the information required for a task, accepts an explicit command and explains the resulting state.
Identity
Stable identifiers
Use durable record IDs rather than display names or list positions.
Change
Versioned contract
Add compatible fields carefully and plan how old installed clients behave.
Write
Duplicate protection
Give retryable actions an operation ID or idempotency key.
Response
Actionable errors
Distinguish validation, conflict, authorisation and temporary failure.
When several systems are involved, use a business system integration layer to keep mapping, orchestration and operational visibility outside the mobile interface.
04
Define what happens between local intent and server acceptance
Connectivity can disappear after the user presses a button but before the app receives a response. The product must distinguish a locally saved intention from a business action accepted by the server.
- name which records may be read from local storage and how freshness is shown;
- allow only suitable actions to be created offline;
- give every pending action a durable local identifier and visible status;
- retry only failures that may succeed later;
- make duplicate submissions safe at the server boundary; and
- surface conflicts or rejections to a person who can resolve them.
Use the offline-first mobile app guide to decide whether the product needs cached reading, offline capture or a fuller synchronised workflow.
05
Design integration failure as a product state
| Failure | System response | User response |
|---|---|---|
| Invalid input | Reject with field or rule detail | Correct before retry |
| Not authorised | Reject and record the decision | Explain access without exposing sensitive detail |
| Record changed | Return current version or conflict | Review and resolve intentionally |
| Dependency unavailable | Queue or fail according to the transaction | Show pending or retryable status |
| Unknown outcome | Reconcile by operation ID | Do not ask the user to submit blindly again |
Logs should connect the mobile operation, API request, integration message and system outcome without putting unnecessary personal or sensitive data into telemetry.
06
Prove one thin vertical slice before broad implementation
- Select one valuable mobile outcome and representative user.
- Identify the systems, owners, data and supported interfaces involved.
- Prove authentication and record-level authorisation.
- Implement one read and one write through the full boundary.
- Test timeout, duplicate, stale-record and unavailable-system cases.
- Add local state only for the approved offline contract.
- Instrument the user outcome and integration health.
- Pilot with representative devices, accounts and data.
This slice exposes the real dependency risk earlier than building a large set of screens against mocked services.
07
Prepare an integration brief the delivery team can test
Record the user and outcome, systems of record, identity source, roles, record-level permissions, data classification, API ownership, supported operations, validation, versioning, rate limits, offline rules, duplicate handling, conflicts, error states, audit needs, observability, test environments and support owner.
Pair it with the mobile app development service, the mobile delivery planning guide and the mobile maintenance guide.
Sources
Primary references
Questions
Frequently asked questions
How should a mobile app connect to an existing business system?
Connect through an authenticated API or integration layer that owns authorisation, validation, mapping, resilience and audit. Do not expose a business-system database or privileged credentials directly to the app.
Can a mobile app connect directly to an ERP or CRM?
It can use a supported ERP or CRM API, but a server-side application boundary is usually still needed to give the app a stable contract, protect credentials, enforce mobile-user permissions and isolate vendor changes.
Should the mobile app contain business rules?
Keep interface and device-specific rules in the app, but place authoritative pricing, eligibility, workflow and record-access decisions on the server so they remain consistent across channels.
How does integration work when the device is offline?
The app stores the approved local state and any permitted pending actions, then synchronises through explicit retry, duplicate-protection and conflict rules when connectivity returns.
What should be tested before building the full app?
Validate identity, one representative read, one representative write, error handling, rate limits, representative data and the highest-risk offline or device interaction in a thin end-to-end slice.
Map the integration
Bring the user journey, systems of record, identity model and one representative transaction.
LCR can define the mobile API boundary, validate the riskiest system dependency and shape a viable first release.