Roll out the mobile app to field workers
For technicians, sales reps, or anyone planning on the go. Provision the resource, create a user that maps to it, and walk them through installation and sign-in.
Before you start
The one thing that makes or breaks this rollout is the e-mail match. A field worker's user account and their resource record have to carry the same e-mail address, because that is how the app works out which resource's schedule to show them. Get it wrong and the app signs in successfully to an empty schedule, which looks like a broken app rather than a configuration slip.
So do the resource first, the user second, and copy the address across rather than typing it twice.
1. Create the resource record
The field worker needs to exist as a resource before they can be scheduled at all. Fill in the e-mail field on the resource, not just the name.
While you are on the resource card, decide whether this person needs GPS tracking. The Enable GPS tracking flag lives here, and turning it on later means coming back to this screen.
2. Create the user account
Create the user account with the same e-mail address as the resource. A forms account is the usual choice for field workers, since they often have no Entra ID identity in your tenant.
For a forms account Dime.Scheduler generates a random password and sends a reset link by e-mail. Field workers should watch for that e-mail: it is how they set the password they will use in the app.
3. Install the app
The app is on both stores, and the installation page carries the direct links and the current minimum OS versions. Check those before a rollout to a fleet of older handsets, because a device that falls short simply cannot install the app and you want to know that before the rollout day rather than during it.
4. Sign in
Two things happen on first launch, and only one of them is obvious.
The sign-in screen takes the e-mail and the password from the reset e-mail. Then, the first time the app runs (or after a reinstall), it also asks which mobile backend to connect to. Choose Production for live use. Sandbox is for evaluation before a production environment exists, and a field worker who picks it will sign in fine and see none of their real work.
Tell people about the backend prompt in advance. It is the single most common support call of a mobile rollout.
5. Enable location tracking, if you need it
Location tracking turns the app into a location sensor, which beats buying dedicated hardware. It is off by default and there are two prerequisites worth knowing before you promise it to anyone:
- Pushing a location onto the map in the web app requires the advanced map license.
- The device must grant the Always location permission. This sounds worse than it is, and it is worth explaining to the field worker rather than letting them discover it in a permission dialog: the app does not track around the clock. It only sends updates during the hours configured on the tracking screen, and the "always" permission is simply what the operating system requires for an app to use location from the background.
Field workers can set their own tracking window and pause it for exceptions.
Set expectations on reliability too, because this is where the feature disappoints people who were promised live tracking. The app asks the device to run its background service on an interval, but the device decides whether to honor that, based on battery, memory, and how often the app is used. iOS is the strictest and can suspend the service outright for someone who has not opened the app in a while. Regular use keeps it running. Location tracking has the current interval and the platform specifics.
Verify
Sign in as the field worker on a real device and confirm their own appointments appear. An empty schedule with a successful sign-in almost always means the e-mail on the user and the e-mail on the resource do not match.
Related
- Onboard a new planner for the desk-side equivalent.
- Optimize routes for a technician once field workers are live.