How do you connect a mobile app to your information system?

Yes, but it requires a clear integration layer. Business objects, statuses, and source-of-truth rules must be normalized across the systems, otherwise the mobile application will only move the inconsistencies around.

Yes. Salesforce can feed the mobile application with accounts, contacts, opportunities, activities, or files through its APIs. The key is deciding which data is genuinely useful on mobile and which actions must flow back into the CRM.

Yes, provided the flows, objects, and security rules are properly scoped. SAP can serve as a source for stock, orders, interventions, items, or reference data, but the mobile layer must remain readable and should not expose the full complexity of the ERP.

You first need to check whether there is a usable export, an intermediate database, a connector, or a way to expose a minimal business API. The absence of an API does not always block the project, but it changes the cost and expected level of reliability significantly.

In most serious projects, yes, at least in the form of a controlled exchange interface. That interface can be REST, GraphQL, a webhook, a connector, or a dedicated backend layer. The most important point is not to bind the mobile layer directly to unstable or poorly governed logic.

You need to define which records can be edited offline, which version is authoritative, when automatic merge is possible, and when human validation is required. Without these rules, conflicts are only postponed until after launch.

Yes, and it is a common case. You then need to review the existing base, identify the useful objects, secure the exchange interface, and avoid duplicating business rules between the internal software and the mobile layer.

In practice, teams usually combine OAuth 2.0, JWT, or OpenID Connect for authentication, TLS for network traffic, role-based permissions, logging, and strict management of technical secrets. Useful security depends as much on governance as on protocol choice.

No. Some data must come back immediately, while other records can wait until the app opens, a background process runs, or the network comes back. The right rhythm depends on the business process and the associated decision.

Yes, if the initial architecture clearly separates the mobile app, the API, business rules, and connectors. A well-designed base lets you add a new ERP, a new back office, or a new workflow without rewriting the whole mobile layer.

Timing mainly depends on the quality of the existing interfaces, the expected security level, the offline requirements, and the number of business rules to formalize. Integration itself is rarely the only issue; the real time often goes into scoping the useful information system around it.

Yes, but you then need to decide where each type of data is authoritative. An account may come from the CRM, inventory from the ERP, and intervention history from an internal database. Without a clear source of truth, mobility will only expose the contradictions of the system.

Very often, yes. That layer secures exchanges, orchestrates synchronization, unifies business rules, and prevents the mobile application from depending directly on the specifics of each connected system.

The project becomes rational when duplicate entry, delays, field errors, or lack of visibility already cost more than scoping a connected application. The real calculation depends less on the mobile layer alone than on the friction removed across the broader information system.