Where your organization has enabled location tracking, the mobile app can record positions during the working day, and the dispatch console's Map view presents current-position freshness and travelled paths. Treat that path as operational evidence to compare with visits and attendance—not standalone proof of presence. Device permission, synchronization and server linkage all affect what is retained.
Before dispatch, confirm the selected branch resolves to the intended address and that the planned times use the organization's expected timezone. During execution, location or attendance evidence should be collected only under the configured consent, permission and retention policy. Afterward, review exceptions against both the plan and device conditions: missing background permission, an offline sync delay or a paused session can explain a sparse path without proving nonattendance.
Tracking is organization-controlled
Nothing is tracked by default. Location tracking is a setting your organization's administrator turns on deliberately, together with how often a position is captured, how many points are batched per upload, and the minimum movement below which near-duplicate fixes are skipped. When the setting is off — or simply absent — the app does not start any tracking and does not even request background location permission. There is no per-user way to switch tracking on; it is an organizational decision, visible to the people it affects.
Tracking is session-bound and visible
Capture runs only inside a checked-in working session:
- It starts at check-in — and the check-in screen discloses that the session records location.
- Pausing the session stops capture; resuming restarts it. Only points captured while actually working belong to the trail.
- Check-out ends capture for the day.
While the trail is being recorded, the device asks for location permission through the standard system prompts and shows the tracking state. The current permission flow requires the configured background/Always permission for tracked check-in and deliberately blocks the check-in until it is granted. It does not reliably degrade to a foreground-only tracked session. If an organization enables this feature, publish that operational requirement before the field day begins and provide a support path for devices whose platform policy cannot grant it.
What is recorded, and who can read it
Each captured point carries position, accuracy, speed, heading and a timestamp. Points can be batched on the device and uploaded after connectivity returns. However, the ingest contract accepts a point whose CheckInPunchId is absent. The mobile client normally bounds capture to session state, but the server does not fully enforce “every point belongs to a check-in” as an invariant. Investigations should compare the point's resource/time with attendance rather than relying on that optional link alone.
Reading is scoped the way record access is scoped: you can read your own trail, and managers can read trails widened by the role hierarchy described in the security model. The map reads current positions, a resource path over a time range and a path associated with a visit plan; long paths may be downsampled for display.
New position rows are stamped with a retention horizon of 90 days. The audited code does not include a dedicated location-point sweeper that guarantees physical deletion at that horizon. Administrators must therefore monitor the actual retention job or database process in their deployment and must not describe the stamped date alone as verified deletion.
Common questions
Is my location tracked whenever the app is installed?
The mobile client is designed to start and stop capture with a working session, but the server accepts points without a session identifier. Organization enablement and the required platform permission are still prerequisites for the normal client flow. Treat client behaviour and server validation as separate controls.
What happens if I deny the location permission?
In the current tracked check-in flow, missing background/Always permission can block check-in. Follow the device prompt and the organization's consent policy, or contact the administrator; do not promise a foreground-only fallback that the current flow does not implement.
Who can see where I have been?
Yourself, and your management line — access follows the role hierarchy your organization already uses for record ownership, not a separate list. Dispatchers see your position and path on the console only when you fall inside their hierarchy scope.
How current is the position on the dispatch map?
As current as the last uploaded batch. The console labels each resource's freshness — live, recent, stale, or off grid — rather than pretending every dot is real-time, and the capture interval and batch size are organization settings, so freshness reflects your organization's configuration.
Related topics
- The dispatch console
- The technician's day
- The security model
- Attendance — the check-in session the trail lives in
- Configuration reference