Privacy · Mobile app

Privacy Policy for TRLLN Collect

Last updated: November 10, 2026

Platform-specific collection

iOS and iPadOS: TRLLN Collect uses Bluetooth Low Energy (BLE) and NFC only while the app is in the foreground. Precise location is optional and, when enabled, is used only while the app is in the foreground. TRLLN Collect does not scan for or collect nearby Wi-Fi data, use BLE in the background, or collect location in the background on iOS or iPadOS.

Android: depending on the enabled and approved app workflow, TRLLN Collect may use BLE, NFC, precise location, nearby Wi-Fi data, and Supernode Mode. Supernode Mode supports the approved Android background BLE, Wi-Fi, and location behavior and runs with the required Android permissions and foreground-service notification.

Introduction

TRLLN Collect (“we”, “our”, or “us”) is a mobile field application that detects nearby Bluetooth Low Energy (BLE) nodes and supports physical asset validation using NFC. This Privacy Policy explains how the app handles information when you use it.

Who we are

The controller of the personal data described in this policy is TRLLN S.L., Plaça de Pau Vila, 1, Ciutat Vella, 08039 Barcelona, Spain. Contact: customer-support@trlln.io.

You use TRLLN Collect through your organisation’s TRLLN account. Your organisation decides who uses the app and which workflows are enabled; for that operational data we act on your organisation’s behalf under our agreement with it. How TRLLN handles your platform account is described in our main Privacy Policy.

Information we collect

Bluetooth Low Energy (BLE)

  • Purpose: we request Bluetooth access to detect nearby BLE nodes matching configured manufacturer IDs and to validate the operational status of associated assets.
  • What: observations may include the hardware MAC address of a matching BLE node on Android, or the platform-provided device UUID on iOS, together with signal and timing information used for operational telemetry.
  • When: on iOS and iPadOS, BLE scanning occurs only while the app is in the foreground. On Android, BLE scanning may continue in the background only when the approved Supernode workflow is enabled, the required permissions are granted, and the required foreground service is running.
  • Transmission: matching BLE observations may be included in telemetry payloads sent to https://api.trlln.io/*.

NFC asset validation

  • Purpose: NFC is used to identify a physical asset and validate whether its associated BLE node is emitting.
  • What: the app reads only the NDEF payload from the NFC tag. The NDEF payload contains the MAC address of the associated BLE node.
  • When: NFC validation is performed as part of an in-app asset-validation flow while the app is active.
  • Validation: after reading the NDEF payload, the app checks for the associated BLE node and may record the validation result as operational telemetry.

Location (GPS)

  • What: when permission is granted and a location fix is available, the app may collect precise GPS coordinates, including latitude and longitude.
  • iOS and iPadOS: precise location is optional and is collected only while the app is in the foreground.
  • Android: precise location may enrich telemetry during active use. When the approved Supernode workflow is enabled and the required permissions are granted, location may also be collected in the background through the Android foreground service.
  • Purpose: location helps associate BLE observations and validation events with the field location where the work occurred.
  • Transmission: available coordinates may be included in telemetry payloads sent to https://api.trlln.io/*.

Nearby Wi-Fi access points — Android only

  • What: on Android, the app may collect the hardware MAC address (BSSID) and signal strength (RSSI) of nearby Wi-Fi access points when the relevant workflow and permissions are enabled.
  • What is not collected: Wi-Fi network names (SSIDs) are not collected.
  • iOS and iPadOS: the app does not scan for or collect nearby Wi-Fi access-point data.
  • Purpose: available BSSID and RSSI information provides ambient location context to complement GPS coordinates in telemetry.

Device identifier

  • What: a stable, hardware-derived identifier (device_id) is generated on the device and included in every scan payload sent to api.trlln.io.
  • Format: a truncated SHA-256 hash derived from hardware properties (Android ID / iOS Vendor ID, device model, board), truncated to 12 uppercase hexadecimal characters and prefixed with the platform name — for example, android_XXXXXXXXXXXX or ios_XXXXXXXXXXXX. This identifier is deterministic and persists across app restarts; it is not a randomly generated UUID.
  • Storage: stored in secure storage on your device.
  • Purpose: server-side device attribution and observability — allows the server to associate scan events with a specific device across sessions. Because it is linked to your signed-in account and sent with location data, it is treated as personal data.

Authentication

  • The app authenticates users via Auth0 (auth0.com), a third-party authentication service.
  • User credentials (email/password or social login) are handled exclusively by Auth0’s hosted login page. The app does not process your credentials directly.
  • Auth0 issues a JWT access token that is stored in secure storage on your device and included as a Bearer token in all API requests to api.trlln.io.
  • For details on how Auth0 handles your data, see Auth0’s privacy policy: https://auth0.com/privacy.

How data is submitted

  • Operational submission: BLE observations, NFC validation results, available location, and Android Wi-Fi context may be submitted to TRLLN services as part of the app’s operational workflows.
  • Connectivity recovery: pending scan and telemetry data may be submitted automatically when network connectivity is restored.
  • Periodic retry: pending data may be retried according to the app’s retry and retention rules. The app does not guarantee that every attempted submission will be delivered.

Local storage and offline operation

  • BLE observations, NFC validation records, Android Wi-Fi context, telemetry payloads, sync status, and retry state may be stored locally in a database on your device.
  • When connectivity is unavailable, pending data may remain queued locally and the app attempts to transmit it when connectivity resumes.
  • The queue uses retry and retention rules, including retry backoff where applicable, for temporary network failures.
  • Local storage and transmission depend on the app workflow, device state, granted permissions, available connectivity, and applicable retention rules.

Data storage

  • Operational data may be stored locally on your device before submission and may be transmitted to api.trlln.io when the relevant workflow submits it.
  • Data transmitted to TRLLN services is associated with the relevant operational records and device identifier for device attribution, troubleshooting, and telemetry correlation.

Legal basis

  • Sign-in, BLE observations, NFC validation and the device identifier: our legitimate interest, and your organisation’s, in operating the asset-tracking service it has contracted and keeping it reliable (Art. 6(1)(f) GDPR).
  • Location and Wi-Fi context during active use: the same legitimate interest, to place BLE observations and validations where the work happened. On iOS and iPadOS location is optional.
  • Background location on Android (Supernode Mode): the same legitimate interest, only when your organisation has enabled Supernode Mode and you have granted the Android permissions. A persistent notification shows while it runs; you can stop it by turning Supernode Mode off or revoking the location permission.

How long we keep it

  • On your device: pending data until it is submitted, or until you uninstall the app.
  • Raw scan data received by our ingestion service: deleted after 7 days.
  • Processed observations (asset positions and status derived from your scans): kept as operational telemetry of your organisation for up to about 9 months.

Who we share it with

  • https://api.trlln.io/* — TRLLN’s endpoint for operational and telemetry data.
  • Google Cloud — hosting of TRLLN services and data (EU, Frankfurt). Data from the app may pass through an ingestion point in the USA on its way to the EU, where it is stored.
  • Okta (Auth0) — sign-in (EU). See Auth0’s privacy policy.
  • Google Maps Platform — nearby Wi-Fi access points (BSSID and signal strength) may be used to estimate a position when GPS is not available (global).

The app does not include advertising or analytics SDKs. We do not sell personal data.

Transfers outside the EU

Where data passes through or is processed by Google outside the European Economic Area, the transfer is protected by the EU–US Data Privacy Framework and the European Commission’s Standard Contractual Clauses.

Your rights

You can ask us to give you a copy of your personal data, correct it, delete it, limit how we use it or object to processing based on legitimate interest. E-mail customer-support@trlln.io from the address linked to your account; we answer within one month and may involve your organisation’s administrator.

  • You can remove the data stored by the app on your device by uninstalling it.
  • You can stop location collection at any time in your device settings.

You also have the right to lodge a complaint with a data-protection authority, in particular the Spanish Agencia Española de Protección de Datos (aepd.es) or the authority of the EU country where you live or work.

Changes to this policy

We update this policy when what the app does with personal data changes, and change the “Last updated” date at the top.

Contact us

Questions about this policy or your data: customer-support@trlln.io.