Staff TrackerSet up Traccar Client for a staff tracking team
Connect a staff phone methodically: confirm its assigned details, test a fresh location and check background reporting before handing the device back to everyday use.
What the client does in the setup
Staff Tracker connects staff phones through Traccar Client. The client obtains location information on the phone and sends reports to the configured tracking service. Staff Tracker then uses the received information in the team workspace. A successful setup therefore involves more than installing an app: the device must be associated with the intended person, use the correct connection details and have permission to report as required.
The product's Tracker area provides the connection instructions for your team. Use those instructions as the source of truth for the device code and service details. Do not copy an example address from a tutorial or reuse another person's configuration simply because it worked on their phone. A technically successful connection to the wrong destination is still a failed setup.
This guide describes a verification process, rather than a fixed sequence of screenshots that may become outdated. App and operating-system menus change. Refer to the current Traccar Client configuration documentation when interpreting a control, and follow the instructions shown for the workspace you are joining.
Prepare the handover before opening settings
Confirm who the phone belongs to, who will use it during the shift and who is responsible for support. Shared work phones need an explicit handover process so that a device's location is not accidentally attributed to yesterday's user. Personal phones require a clear agreement about the intended work arrangement and what to do outside that arrangement.
Make sure the person setting up the device can explain the purpose of tracking and the steps to report a problem. Configuration is much easier when the worker understands what a normal result looks like. “You should see a recent update associated with your assigned device” is more useful than asking them to tap through settings without context.
Choose a time when the phone can obtain a usable location and connect to the network. Trying to diagnose a new installation in a basement with weak coverage introduces several uncertainties at once. Establish a straightforward successful test before testing more demanding places.
- Confirm the intended staff member and device assignment.
- Open the current connection instructions in the correct workspace.
- Check that the phone has sufficient charge and connectivity.
- Agree who will observe the result in the management view.
- Explain how to pause the handover and ask for help if anything differs.
Keep device identifiers distinct
The device identifier allows incoming reports to be associated with the expected device. Treat its assignment carefully. If two devices use the same identifier, the resulting history can become confusing because reports may appear to come from one device when two people are actually moving independently.
Read the assigned code from the workspace rather than guessing its format. Compare the complete value after entering it, including any characters that are easy to confuse. When someone replaces a phone, use the workspace's intended replacement process and verify which device remains active. Do not leave both phones reporting under the same identity unintentionally.
Avoid sending configuration screenshots to broad group chats. They may contain connection details or staff information that other participants do not need. Share a description of the symptom with the designated support person, using the organisation's approved channel for any sensitive setup information.
Check the first location while the app is open
After following the workspace instructions, enable the client for the agreed test. Ask the coordinator to confirm that the expected staff record receives a fresh location. Check the timestamp as well as the map position. An old point that was already on the map does not prove the new installation is working.
If no update appears, return to the simplest checks first. Confirm the phone is online, that location access is available and that the connection details match the instructions. Change one thing at a time and repeat the observation. A list of simultaneous changes may produce a working device, but it leaves you unable to explain which issue was responsible.
Check the identity displayed alongside the location. If the point appears under a different person, stop the test and correct the assignment before continuing. A mistaken identity is more serious than a slightly delayed point because it can mislead every subsequent attendance or dispatch decision.
Test background operation separately
Once foreground reporting works, lock the screen and use the phone as it will normally be used during a shift. Move through a short, known route and allow time for the next observation. Have the coordinator check whether the new timestamp and location arrive without the worker reopening the client.
The official Traccar troubleshooting guidance identifies location permissions, background execution and battery restrictions as relevant checks. The exact controls depend on the platform and device. Follow the appropriate instructions rather than assuming that every Android manufacturer or iPhone version uses identical menu labels.
Do not use a successful foreground test as a substitute for this step. A phone can appear correctly configured while open on the setup desk and then stop producing useful observations during ordinary background use. Catching that difference during onboarding saves repeated explanations later.
Choose settings around the operational need
Before changing accuracy or reporting controls, identify the problem you are trying to solve. Is the team missing an arrival, receiving a stale location during travel or using more battery than expected? These are different issues and may require different tests. Increasing every setting indiscriminately is not a diagnosis.
The client documentation explains that reporting behaviour depends on several factors and is not guaranteed solely by a configured interval. Use an observation log to judge the result in practice. Record the starting configuration, the intended change and what happened during a comparable route.
Keep configuration changes proportionate to the use case. A team that only needs a reliable view of site visits may have different needs from a dispatcher coordinating active travel. Establish what is adequate for the real decision before collecting a denser stream of observations.
Test one realistic workplace journey
After the basic setup checks, use an actual work route. Start outside the workplace, arrive through the ordinary entrance, remain on site and then leave. Compare the latest locations and any geofence entries with the journey you expected. This checks the connection, the phone behaviour and the workplace configuration together.
If the phone reports correctly but an arrival is missing, do not immediately reinstall the client. Review whether the boundary includes the entrance and whether the sequence contains usable locations on both sides. A reporting issue and a boundary issue can look similar in the attendance view but have different causes.
Keep the pilot's purpose explicit. The worker is helping verify the configuration, not being evaluated against an untested system. Ask what they noticed: an unexpected permission prompt, an apparent connection problem or an impractical instruction may reveal more than a dashboard observation alone.
Write a short device support record
A useful support record includes the device model, operating system, client version if available, assignment, test date and outcome. Record the settings relevant to the issue without collecting unrelated personal information from the phone. Keep the record in the appropriate internal location rather than embedding private details in a public help page.
Include a plain-language symptom when something fails. “The last update remains at 10:15 after a ten-minute outdoor walk with the screen locked” is actionable. “Tracking is broken” is not. State whether the same phone reports while open and whether another device at the site behaves differently.
Document the eventual resolution and the follow-up test. If a permission change solved the problem, note the observed result after that change. If the cause remains uncertain, say so rather than converting a temporary recovery into a confident explanation.
Example: a replacement phone
A field worker receives a replacement work phone on Monday. Their old phone is still powered on at the depot. The coordinator notices alternating locations between the depot and the first job and initially suspects poor location accuracy. The actual issue is that both phones were configured for the same staff assignment.
The team stops reporting from the retired phone, confirms the intended assignment on the replacement and performs a new background test. The coordinator now sees a consistent sequence. The handover checklist is updated to include retirement of the previous device, preventing the same avoidable confusion next time.
This is an illustrative troubleshooting example. It shows why checking identity and device ownership belongs near the beginning of setup, rather than being treated as an administrative detail after testing the map.
Finish with a clear handover
Before calling setup complete, ask the worker to explain what to do if the phone stops reporting. They should know which support channel to use, what basic observation is helpful and what the agreed working arrangement requires. The coordinator should know what a normal update looks like and when to use a fallback contact method.
Schedule a brief review after ordinary use rather than assuming the desk test covers every situation. A full shift may expose charging, coverage or background-operation issues that a short walk does not. Use the review to improve instructions, not to add unnecessary monitoring or repeated checks.
Frequently asked questions
Can I copy another employee's device code?
Use the code assigned to the intended device or person in your workspace. Reusing another assignment can cause locations to be attributed incorrectly. Verify the identity shown in the dashboard as part of the first successful test.
Why does the app work only while it is open?
Background permissions or device restrictions may be involved, but diagnose the actual phone rather than assuming a cause. Compare foreground and locked-screen tests, then follow the current platform and Traccar troubleshooting instructions.
Is choosing a reporting interval enough to guarantee updates?
No. The configured value is only part of the reporting behaviour. Permissions, device state, location availability and connectivity also matter. Verify the result with realistic observations instead of promising an exact update schedule.
When is a new phone ready for normal use?
When it reports under the correct identity, passes a foreground and background test, works on a representative workplace journey and has a clear support handover. Keep a brief record of those checks so future troubleshooting starts with evidence.