Mobile
Connecting Salesforce with a mobile app
A customer checking an order on a phone needs a different app from an employee recording a visit. Before connecting either one to Salesforce, decide what people need to do and which data they can use.
Start with what people need to do
List the main tasks for each type of user, then work out which records and actions they need. For example, a customer may need to see an order status while a member of staff needs to update it. The app does not need to display every field in Salesforce.
Decide which system owns each record
For customers, products, stock and orders, name the source of truth. Define which updates the app may make and how they reach the other systems. A successful API request does not automatically mean every connected system has finished processing the change.
Decide what works offline
If the app must work without a connection, decide what it can read and change offline. Define how long cached information remains useful and how conflicting updates are resolved. Some actions, such as a stock-sensitive purchase, may need an online check.
Test the difficult moments
Include expired sessions, duplicate taps, interrupted requests and changed access rights in acceptance testing. Agree who owns the app, the integration and the Salesforce configuration after launch. These responsibilities matter as much as the first release.
What to prepare before asking for an estimate
Write down a few examples of what someone should be able to do in the app. Include what they see and what changes in Salesforce when they finish. The questions below will help define the work.
| Decision | What to define |
|---|---|
| People and tasks | Who uses the app, what they need to finish, and which records they may access. |
| Data ownership | Which system owns customers, products, orders and stock, and who can change each record. |
| Connection failures | What remains available offline, what must wait, and what the user sees when an action fails. |
| Release acceptance | The scenarios that must pass, the person who approves the release, and the support owner. |
When is an order actually confirmed?
If a customer submits an order from a phone, decide when the app can say the order is confirmed. Sending a request, reserving stock and accepting the order may be separate steps. Design the messages and retry behaviour around those steps so the customer knows what has happened.
Before development starts, you should have a list of user tasks, a map of the data being exchanged and examples the finished app must handle. These give you a basis for estimating the build and checking the result.
