Evaluate mobile CRM around the work a field colleague needs to complete: finding the right customer, preparing for a visit, recording its outcome and handing the next action back to the team. Treat offline behaviour and device access as explicit parts of that workflow. A screen that opens on a phone is only the beginning of the assessment.
Which mobile product are you assessing?
Microsoft describes the Dynamics 365 Sales mobile app as designed for core field seller scenarios. The Dynamics 365 Sales mobile app is available for installation on iOS and Android. The Sales mobile overview is a useful starting point for identifying the actual application before discussing its capabilities.
Microsoft says the Sales mobile app does not work with Dynamics 365 Customer Engagement on-premises. Write the application name, deployment type and intended devices into the requirements brief. If someone demonstrates a different application under a similar product family, ask them to identify that change before accepting the result as evidence.
Use a hypothetical field visit to a synthetic customer called Sample Workshop. The proposed exercise is to find its contact, inspect the planned meeting and record the next action. Use invented contact details throughout, and record actual observations only when the team performs the exercise.
Choose the important tasks before selecting the screen layout. A salesperson, supervisor and administrator may each need a different view of the same visit. Ask each role to describe what it needs to know and what it should be permitted to change.
What must be available before the visit?
The Dynamics 365 Sales mobile app can show reminders about customer meetings. Assess the proposed meeting view against the questions the colleague needs to answer: who they are meeting, why the visit is taking place and which earlier commitment needs attention. Specify the information to show rather than assuming that every CRM field belongs on the first screen.
Ask the evaluator to find Sample Workshop using the intended search route and distinguish it from a similarly named training record. Keep the selected customer reference visible in the assessment notes. A matching display name alone should not settle which record receives a new activity.
For the device-security part of the brief, identify who owns the device, who may sign in and which customer information is needed locally. Ask the organisation’s administrator to demonstrate the chosen access and device controls in a test setting. Record the configuration actually assessed; do not infer those controls from an app-store listing.
Include a handover scenario. If a colleague takes over the visit, decide which information should become available to that person and who authorises the change. The requirement should describe the business handoff clearly enough for the implementer to assess it.
What does offline mean for the selected app?
Microsoft’s offline-actions guide covers the Sales Hub app on Dynamics 365 for mobile. Keep that offline-actions documentation separate from the Sales mobile overview when recording the evidence. Capabilities should remain attached to the app and configuration that the source describes.
An administrator must associate a mobile offline profile with the user before offline work. Ask the administrator which records the intended user profile includes and why. Use the training customer to assess the result before removing connectivity. Keep the preparation steps in the exercise record so another reviewer can repeat the same conditions.
Offline lookup fields in that guide can reference only downloaded records. Include a lookup to a record that was deliberately left outside the training download. Observe how the interface responds and decide how staff should handle that situation. This exposes a meaningful requirement: the field colleague needs a clear route when the required record is unavailable.
Distinguish reading a previously available record, editing it locally and making the change visible to the wider team. Ask the evaluator to record each stage separately. The acceptance notes should say what was observed after reconnection and which uncertainty, if any, remains.
Which actions should wait for a connection?
The same guide says business process flows are not supported for mobile offline. Microsoft lists adding stakeholders, competitors and sales teams to opportunities as unsupported offline. These documented boundaries help frame the workflow discussion without treating every action on a record as equally available offline.
List the visit actions the business actually requires. For each action, ask whether it can be completed offline in the selected configuration, needs preparation or should wait for a connection. Keep an alternative operating instruction for the actions that cannot be completed in the proposed conditions.
When connectivity returns, ask a second authorised user to inspect the training record. Compare the relevant fields and activity references with the changes made on the device. Record any conflict or unresolved update as an observation requiring a decision, rather than describing the exercise as successful in advance.
Plan how the colleague should recognise unfinished work before leaving the visit. The proposed process might include checking a local activity list or recording a follow-up reference, but the assessor should verify the route the selected implementation actually offers.
How should a visit-to-handoff assessment be recorded?
Microsoft lists adding notes and creating contacts among its Sales mobile post-meeting actions. Use those documented actions to build this original visit-evidence matrix. It connects the field task to the information another team member needs after the meeting.
| Visit boundary | Evidence to inspect | Decision to record |
|---|---|---|
| Preparation | Selected app, device and customer reference | Is this the intended working context? |
| Before disconnecting | Relevant profile and available training records | Which information is prepared for offline use? |
| Customer lookup | Downloaded and deliberately absent examples | What should staff do when a record is unavailable? |
| Visit outcome | Actual note or record change | Is it attached to the intended customer? |
| Reconnection | Comparison from a second authorised account | Has the observed change reached the expected record? |
| Team handoff | Next action and responsible colleague | Who has accepted the follow-up? |
Keep device access questions alongside this matrix, including the procedure for a reassigned or unavailable device. Ask the administrator to identify the relevant settings and the person who maintains them. Those requirements deserve explicit evidence rather than a general statement that the app is secure.
Finish the evaluation with an actionable gap list. Each gap should identify the affected task, the observation and the owner of the next decision. This gives the team a practical basis for choosing a controlled pilot scope.
For the surrounding integration work, see web development. Send Spout your mobile CRM requirements with the visit tasks, intended devices and the offline actions that matter most.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.