How do you integrate ERP with a field sales mobile app?

A sound ERP–mobile integration starts by naming one field workflow and the system of record for each data type. The app should not calculate prices, discounts or credit limits on its own when those rules belong in ERP. It should retrieve the required data through an integration layer, capture the rep’s actions and pass them to the correct system under explicit controls.

The common mistake is to move desktop ERP screens onto a phone. A mobile workflow should be shorter: prepare for a visit, find the account and product, confirm terms, create an order, capture a note and set the next action. Data scope, permissions and offline behaviour follow those jobs rather than the number of modules available at headquarters.

ERP commonly owns master data, pricing, discounts, credit limits, inventory, commercial documents and fulfilment status. CRM owns the relationship, opportunities, visits, tasks and contact history. PIM or a product catalogue may be the better source for descriptions, media, variants and compatibility. The mobile app presents the required slice and captures user actions without becoming a competing source of business rules.

Ownership must be defined at field and operation level. One system can own availability reads, another order writes and another visit notes. When that responsibility is unclear, teams reconcile discrepancies manually and synchronization becomes a source of errors instead of automation.

• Account and terms: name the owner of company data, credit limit, currency and price list.
• Product: assign ownership of SKU, variant, description, unit, media and availability.
• Order: separate draft, rule validation, document number and fulfilment status.
• Visit and activity: decide what belongs in CRM and what remains app-local.

Offline-first means that a critical subset of the workflow remains available without reliable internet and local changes synchronize later. It does not mean a full ERP copy on the device. The offline profile should limit accounts, products, price lists and history to the user’s role, territory and practical working horizon.

The app needs a local data source, a durable operation queue and visible synchronization status. Users should know whether a price or stock value is current, whether an order is waiting to upload and whether the server rejected a change. Hiding conflicts behind a generic “synced” message creates commercial risk and makes support harder.

Price, availability, catalogue, history and visit notes tolerate different delays. For each data class, define flow direction, acceptable freshness, retry behaviour and conflict policy. A financial action or stock reservation may require an online check even when order preparation works offline.

• Accounts and catalogue: initial download followed by incremental updates.
• Prices and discounts: rule version, timestamp and mandatory revalidation before commitment.
• Availability: short validity and a clear indication when the value is cached.
• Orders: local draft, unique identifier, upload queue and an ERP acknowledgement.
• Notes and visits: local persistence, retries and a visible error state without losing input.

Security begins with minimal data scope and roles, not with encrypting everything after the fact. Mobile access should use user identity, short-lived tokens and server-side authorization. Sensitive local data needs secure storage, while communication requires encrypted transport and protection against replaying the same operation.

The audit trail should connect user, device, app version, operation, time, rule version and the system-of-record response. The organization also needs remote session revocation, an app update policy and testing proportional to the data and workflow risk.

A packaged ERP mobile app or field-sales product is usually the best starting point when the company has a standard workflow, a supported source system and can accept the available roles, order screen and synchronization model. A custom app adds little advantage when the only requirement is mobile access to the same functions.

A custom solution becomes justified when the workflow spans several systems, proprietary pricing, a distinctive visit model, industry forms, devices, roles or a user experience that configuration cannot simplify. A mobile CRM for advisers creates value when it shapes the real working day rather than merely opening the customer database on a smaller screen.

Metrics should cover workflow, data and user behaviour. Compare visit or order preparation time, manual corrections at headquarters, queued operations, rejected writes, freshness of critical data, active usage and support cases. Installing the app is not the same as adopting it.

Quality review must also cover edge cases: no signal, expired price, changed credit limit, a large order, duplicate retry, lost device and ERP outage. The BERG System case study demonstrates a mobile adviser tool where sales workflow, calendar, customer data and security have to operate as one product.