1. Who this policy covers
Evidaro is a field-operations platform used by organisations to assign outlet visits, record field activity and review visit evidence. This policy applies to the Evidaro mobile app, web platform and public demo enquiry form.
Each field user receives an account from their organisation; the mobile app does not provide public self-registration.
- Operator
- Abdul Shakur
- Privacy contact
- shakurabdul134@gmail.com
- Address
- Kampala
2. Information collected
Account and organisation information
We process the name, registered email address, phone number, role, company affiliation and account status associated with a field user. We also process the email or phone identifier used to request a one-time login code, the code record, and authentication tokens used to keep a signed-in session.
Demo enquiries
If you request a demo through the public website, we save the name, work email and organisation you provide, plus any optional phone number and message. We record when the request was received and whether an email alert was sent.
Field-work and visit information
Evidaro processes assigned visits, project and outlet details, visit dates and status, check-in/check-out times, checkout notes, sales quantities and values, stock counts, shelf measurements, new-product availability, merchandising activities and any notes submitted in the app. Outlet records may include business contact details, addresses and outlet coordinates supplied by the organisation.
Precise location information
Location is collected to verify a daily trade-session check-in against an assigned outlet geofence and to record the agent's final check-out position. A daily trade session may be checked out from wherever the agent is; final checkout is not limited to an assigned outlet. After a successful check-in, the app records route points while the daily trade session remains open, including while the app is not visible. Tracking follows the agent between assigned outlets; it does not require a separate check-in/out at each outlet and is not intended to collect off-duty location.
The current implementation requests updates at roughly two-minute intervals or after about 75 metres of movement, subject to the device operating system, GPS availability and battery controls. These records can include latitude, longitude, accuracy, speed, heading, altitude, the original capture time, the server-received time and whether the device reports a mock location. Android uses a visible foreground-service notification during an open trade session. On iOS, the operating system may show its background-location indicator. Tracking is stopped when the user checks out or signs out. If a location cannot be sent immediately, it can be queued locally and uploaded later with its original capture time.
Camera, selfies and photo evidence
A live selfie is required to complete a visit check-in. A user may also take a photo for a merchandising activity. The app currently uses the camera rather than the device photo library. Uploaded evidence can include the image, original filename, file type and size, capture/upload time, extracted image metadata, image hashes used to detect duplicates, and location data where available.
Device, technical and audit information
For visit verification and troubleshooting, the app sends the device platform, model, operating-system version and app version with check-in, check-out and location-log submissions. The web backend also records audit information such as IP address, user agent, event type and time for relevant account and field-work actions.
3. Why we use this information
- To authenticate field users and maintain a signed-in session.
- To show assigned visits and support check-in, check-out and activity submission.
- To verify outlet attendance and identify geofence or suspected mock-location issues.
- To create visit evidence, compliance alerts, reports and performance summaries for the relevant organisation.
- To detect duplicate evidence uploads and investigate operational issues.
- To synchronise field data that was captured while connectivity was unavailable.
- To review and respond to demo enquiries submitted through the public website.
4. Permissions and your choices
After sign-in, Evidaro presents a setup flow before requesting permissions. It explains foreground precise location, background location during an open trade session, camera access, the authorised-manager visibility of movement history, and this policy. The app requests foreground location first, then background/Always access separately, and requests camera access separately. Completing setup does not start tracking.
You can decline or later revoke these permissions in your device settings. Without camera access, a user cannot complete selfie-based check-in. Without foreground location, the app cannot complete location-verified check-in or check-out. Without background/Always access, ongoing route tracking may be limited when the app is not visible. Device location must also be enabled. The app shows a recovery message and settings link when it detects that required permission or device location is unavailable.
5. Storage, offline data and retention
The app stores the session token, a limited user profile, and pending route points or a deferred checkout in platform-secure device storage until they can be synchronised. Logging out clears the saved session credentials; it does not itself remove field records already sent to the backend.
Submitted visit records, evidence and demo enquiries are stored by the Evidaro backend. In the current implementation, submitted images use Laravel's public storage disk and are delivered through /storage URLs. The service operator must review hosting and media-access controls before production release. The current source code also does not define an automatic retention period or scheduled deletion process for accounts, visit records, location logs, photos, demo enquiries or audit logs. A retention period and deletion procedure must be set by the service operator before publication.
6. Who can receive or access information
Information is sent to the Evidaro backend at the organisation's configured service address. Authorised administrators for the relevant organisation, and authorised platform super administrators, can access operational records according to their role and company scope.
A configured email-delivery provider may process the registered email address and one-time login message when Evidaro sends a login code. The specific provider is chosen in the deployment configuration. The current Flutter dependency list does not declare advertising, analytics or crash-reporting SDKs.
Public demo enquiries are available to authorised platform super administrators. If SMTP email alerts are configured, the selected email provider and business recipient also receive the enquiry details.
Evidaro does not include advertising functionality in the reviewed code. We do not describe any sale of personal information in this policy.
7. Security
The production mobile configuration uses an HTTPS API address, and the app uses platform secure storage for its saved session token and limited profile. Access to operational data in the web platform is role- and company-scoped in the application code. These controls do not replace the need for the operator to maintain appropriate hosting, access-control and incident-response practices.
8. Account and data deletion requests
The current app has no public account-registration or self-service account-deletion feature. It also has no implemented public deletion-request workflow. A field user who needs an account or data-deletion request should contact the organisation that issued their Evidaro account, or the privacy contact listed above when available.
The service operator must confirm how deletion requests are received, verified and completed before this policy is submitted to Google Play. This policy does not promise a deletion timeline because none is configured in the current application.
9. Changes to this policy
We may update this policy when Evidaro's data practices, permissions, service providers or legal requirements change. The updated version will be posted on this page with a revised “Last updated” date.