Appearance
Privacy and personal data
What Omaya knows about people, how to measure a building without knowing who anyone is, and the controls for the personal data you do keep. Written for the person who has to answer the data-protection officer, the works council or an employee who asks "is this tracking me?".
Two very different kinds of measurement
| Anonymous sensors | Tags bound to a person | |
|---|---|---|
| What | Radars, people counters, door counters, presence sensors, environment sensors | A BLE badge or wristband, bound to a person on People and assets |
| What Omaya learns | How many people are in a room, for how long, and when it was empty | Where that named person was, room by room, and when |
| Identifies anyone? | No. A radar sees positions, a counter sees a crossing; neither carries a name | Yes. This is personal data |
| Reports it feeds | Space Utilisation (including Buildings and Desks), Footfall, Room Usage, Environment, Meeting Room insights, the walk-in and no-show logic | Attendance and Office days by team, the Entity Tracker, Movement Replay, Roll Call, Fall detection |
A tag bound to an asset (a trolley, a wheelchair) is not personal data. A tag nobody is bound to is counted as "a tag" and nothing more.
Measuring a building without knowing who anyone is
If your goal is the real-estate question — which rooms are used, how many desks you need, which floor could go — you do not need to track people.
- Put counting sensors or radars in the rooms you want to measure, and desk sensors on desks (mark those zones as Desk under Spaces → Zones → Kind of space).
- Do not bind tags to people. Space Utilisation, the Buildings scorecard, the Desks card, Footfall from door counters and the Meeting Room app all work from the sensors.
- Check Reports → Space Utilisation: a zone's source should read everyone (sensor), not tagged people only.
What you give up: Attendance, Office days by team, the Entity Tracker and Roll Call need to know who someone is. Decide that per use, not by default.
When you do bind tags to people
- Tell people, and have a reason. Safety (roll call, man-down, panic buttons) is the usual one. Write down why each team carries a tag.
- Limit who can see it. A role can be limited to certain labels, so a team lead sees their own team and no one else (System → Roles). Reports that show people are separate permissions.
- Homes stay private. Outdoors, Omaya works out where a person spends the night and shows them as At home, never where that is, unless you choose to show homes. See How Omaya knows someone is at home.
- Looking is recorded. Opening a report or the people list is written to the Activity Log, with who and when.
- Keep it only as long as you need it. System → Configuration → Data Retention sets how many days of history are kept; older months are deleted by the nightly clean-up. See Organisation settings.
A person asks what you hold about them, or to be forgotten
Your Omaya provider can find every record that could be that person — their admin account, mini-app login, their person record with its tag history and location trail, meeting attendances — export it as a file, and anonymise it. Each export and erasure is itself recorded, as proof the request was honoured. Ask your provider with the person's name, email or staff number.
Where the data lives and how it travels
- Each organisation has its own database. Your people, rooms and history are not stored alongside another organisation's.
- Gateways connect out, nothing connects in. A gateway only needs an outbound internet connection to Omaya, so it can sit on its own network or a 4G router, apart from your office network.
- Sign-in. Two-factor authentication is required for every administrator, or sign-in goes through your own identity provider (single sign-on). API keys are stored only as a hash and can be limited to your addresses.
Related
Who did what: Activity Log and Usage · People and assets · Organisation settings