Administration

Who can do what, what the platform has been doing, and the settings that change how it behaves.

Every page in this chapter is scoped to the organisation. Equivalent cross-organisation pages exist for the platform operator, on a menu that organisation users do not see.

NOTE

Most pages in this chapter require a permission. A user who cannot see a page lacks that permission in their role. Roles are edited under System > Roles; see Administration.

System

Admins

Menu path: Choose System > Admins (/admin/system/admin).

The administrator accounts for the organisation, and the role each one holds.

Application scenario: Adding and removing colleagues, and resetting access. Reset MFA is the answer to "I lost my phone": the person sets two-factor up again at their next sign-in. Switching an account off signs that person out at their next click.

The list. Tiles count Admins, those with No two-step sign-in, those Not signed in for 30 days and those switched Off; a tile opens its tab (All, No two-step, Dormant, Off), beside a search and a role filter. Each row has an on/off switch. Clicking a row opens the person: their role, when they last signed in and last changed their password, and the actions for the account.

Related documents: Signing in

Roles

Menu path: Choose System > Roles (/admin/system/role).

Roles, and the individual permissions each role grants.

Application scenario: Deciding who sees what. Almost every menu item is permission-gated, so a colleague reporting a missing page is usually a role question rather than a fault. The AI Reporting assistant reads an app's data only for roles holding that app's view-report-ai-app-… permission, one per app. Entity access can limit a role to the people and assets carrying chosen labels: it narrows the Entity page, the Entity Tracker and the entity pickers, and leaves reports unlimited.

Area by area. Tiles count Roles, those that Can change access (they can add admins or change roles, so can give themselves more), those Limited to labels and those Not used by any admin; a tile opens its tab. Each row shows the areas the role reaches — everything, some changes, or view only. In the editor each area is set to None, View or Full; open an area only to choose its permissions one by one.

Activity Log

Menu path: Choose System > Activity Log (/admin/activity).

Everything that happened in the organisation, in order: what administrators and app users did, every command sent to a device, what the AI assistant changed, and what happened to the system on its own — gateways going offline and coming back, devices going silent, low batteries, scheduled reports that failed, webhooks that gave up and connectors that started failing. It opens on the last 7 days without page views; tiles count Needs a look, People, Devices, System and AI assistant over that time, and a tile opens its list.

Application scenario: Answering "who changed this?", "what happened overnight?" and satisfying an auditor. Full timeline shows every event in order; Needs a look keeps only deletions, failed or blocked sign-ins, password and role changes, admin accounts added, removed or switched off, commands that did not go through and system problems. In the timeline, lanes narrow it to People (with Changes, Deletions, Sign-ins and In the apps), Devices, System, AI assistant or Page views. The chart above the list shows each day by lane; a bar opens that day. Export follows what is shown.

Prerequisites: View Audit Trail. The History views on devices, gateways, rules and administrators need it too.

How it ended. A gateway going offline, a device going silent, a connector failing or a zone over capacity says underneath when it came back and how long it was out, or that it is still out; the row for the recovery says how long it lasted. Rows stay where they happened.

History on each record. Devices (the History tab in the device panel), gateways and administrators (the bottom of their panel) and rules (History in the rule editor) show their own rows from the last 90 days, with a link to this page narrowed to them.

Integrity. Every record gets a SHA-256 checksum when it is written, and every night every record is checked against it. The line under the title says when the last check ran and whether anything had changed. The CSV and PDF exports check each exported record again, say how many were unchanged, and end with a fingerprint of the records exported.

Related documents: Auditing

SLA & Uptime

Menu path: Choose System > SLA & Uptime (/admin/system/uptime).

The organisation’s service levels over the last 7, 30 or 90 days: Gateway uptime (the share of the range each gateway's data was arriving, from the outage log, with its outages and time down), Online now (gateways sending right now), Devices heard in 24 h (active devices heard from by any reading, with a link to the silent ones) and Rule actions that worked.

Application scenario: Reporting against an SLA. Every figure is scoped to the organisation. The Gateways table gives each gateway's own uptime and outages, and its name opens its outages in Gateway Availability; Rule actions per day shows where actions failed.

Prerequisites: Uptime comes from the gateway outage log, so time before the log began counts as up; the page says so when the range starts earlier. A figure with nothing to measure yet (no gateways, no devices, no rule actions in the range) reads No data yet rather than 100 %. Days follow the organisation's time zone.

Configuration

Menu path: Choose System > Configuration (/admin/config).

The organisation’s settings in one place: general settings (timezone, date format), gateway timing, indoor positioning tuning, outdoor GPS tuning, monitor and notification intervals, organisation profile, notifications, single sign-on, fall detection, scheduled reports, starter packs, licence, data retention and the AI model.

Application scenario: The page behind most "why does it behave like that?" questions. Two settings are worth knowing about: data retention, which decides how far back any report can look, and detection speed, which trades how quickly a tag is shown in a new place against how often it flickers between two.

Starter packs. One guided setup per industry: the rules, scheduled reports, dashboard and settings that suit it, previewed against what the organisation has before anything is created, and removable later. The pack for the industry on the organisation profile is offered first. See Start from an industry pack.

Outdoor & GPS. For trackers with their own GPS: how long standing still takes to become a stop, how close together counts as still, when indoor positioning wins, and how stops are named. See Indoor and outdoor.

Fall detection. The Fall detection card opens its own page: the master switch, whether every supported tag is watched or only those a rule names, the sensitivity, and the alerts — ask the person "Are you OK?" for a set time, then, without an answer, open a critical incident in Security Watch for its guards — plus rest places where lying down is normal, and where each tag is worn. Alerts are off to start with, so suspected falls are only recorded in the Fall & Man-down report until the results are trusted.

Single sign-on. The Single sign-on card opens its own page, where administrators can be let in with the organisation's Microsoft Entra ID, Okta, Google Workspace or other OpenID Connect account, and where the organisation can be made SSO-only. It also gives the two links worth putting on the intranet: the login page with the tenant ID filled in, and a direct single sign-on link. See Signing in.

Schedule Report

Menu path: Choose System > Schedule Report (/admin/system/schedule-report).

Reports emailed on a schedule, to a list of people, as PDF or spreadsheet: Footfall, Entry / Exit, People Count, Dwell Time and Attendance for the last full days, Space Utilisation, environment and compliance reports, the alert digest and the monthly summary, among others. A schedule can be limited to one venue. Attendance, Asset Utilisation, Gateway Availability, Panic & Incident Response and Access Review are offered only to roles that can open those reports (Access Review: View Audit Trail), and are sent only to chosen administrators who can. Access Review lists who can get into the console and what changed about it over the period: accounts added, removed or given another role, role changes, failed sign-ins, deletions, administrators with no sign-in for 30 days or without two-step sign-in, and the Activity Log integrity check. The Monthly site pack covers the last full calendar month for the whole platform, one short section per area plus the switched-on apps, following the permissions of the administrator who saves it; Preview shows the whole pack. It also sends the mini apps' reports, grouped by app, to administrators, the app's users or any address; schedules made inside an app are listed as "App — made by name" and can be paused, resumed or deleted here.

Application scenario: The weekly Monday-morning figure that nobody has to remember to run. Tiles count the schedules Total, Active, Paused and with Errors, and a tile opens that filter. Each schedule's card can be paused and resumed, and Test sends it now to its recipients.

Prerequisites: An email address on whoever receives it. A schedule with no administrator and no extra address chosen goes to the organisation's first administrator — the earliest Admin account that is active and has an email address — and the form says who that is; with no such account, nothing is sent.

The monthly summary. Every new organisation is given one, sent on the 1st to the first administrator: for the last 30 full days, visits, door entries, the most inside at once, the most people and tags in one room, the top zones, rules fired and gateway health.

Related documents: How many were here: having them emailed

Usage

Menu path: Choose System > Usage (/admin/usage).

What the organisation used in a month — the plan against what it includes, AI tokens, messages sent, alerts, webhooks, data received from gateways, sign-ins, scheduled reports and API calls — compared with the month before, and anything that did not get through.

Application scenario: Checking headroom before a rollout, finding out which channel or AI feature is behind a bill, and seeing who actually uses the platform. Needs attention comes first: failed messages grouped by cause, a scheduled report that failed, API keys about to expire, many failed sign-ins, and devices or AI near the plan's limits. Your plan sits under it. The detail is under the tabs Messages, AI, Data in, People, Reports, API and Failed; pick another month at the top, and Export CSV downloads it.

AI tokens. Tokens on Omaya's key count against the allowance; tokens on the organisation's own key are billed to the organisation by the provider and never count against it. The AI tab splits each provider both ways.

E-mail: who sent it. Every e-mail Omaya sends for the organisation — visitor passes, rule alerts, scheduled reports, Security Watch escalations, facility requests — goes through the organisation's own SMTP connector when one is enabled, and through Omaya's mailer when none is. This panel counts the month both ways, with the provider under each, showing whether the mail leaves under the organisation's domain or under Omaya's.

Labels

Menu path: Choose System > Labels (/admin/system/tag).

Free-form labels that can be attached to venues, zones, gateways, devices and entities (people and assets).

Application scenario: Cutting across the hierarchy — marking everything installed in one phase, or everything a particular contractor maintains, then filtering on it. A label also does work elsewhere: a rule can watch a Label (every fridge, everyone on night shift), Label Fields on the Entity page add fields to everything carrying it, and a role's Entity access can be limited to chosen labels.

The list. Tiles count Labels, those For entities, those For places and devices and those Not used yet; the tabs All, Entities, Floors and zones, Gateways, Devices and Not used sit beside a search. Each row says what the label is on ("10 entities, 2 zones"), and clicking it opens the label.

Data tables

Menu path: Choose System > Data tables (/admin/manage/data-tables).

The organisation's own tables: name the columns, say how long to keep rows, and rules fill them — one row each time a rule fires, with the reading and the place. Custom Reports read them beside the built-in tables.

Application scenario: The report the platform does not have. Two sensors on one corridor, a count that only makes sense on one site, a log of every time a threshold was crossed with the value it crossed at: put the columns here, point a rule at it, chart it.

Prerequisites: A rule with the action "Add a row to a data table" — nothing is written until one fires. Rows older than the table's retention are pruned every night, so a table cannot grow without limit; set the rule's Repeat at most every to how often the thing can really happen, or a condition that stays true fills the table a row a minute.

The list. Tiles count Tables, Rows stored, Rows, last 24 h and Tables with no rule; the tabs All and No rule yet and a search sit over the list. A row opens the table: the rules that fill it, its columns and the key Custom Reports know it by.

Related documents: Data tables: your own report

NOTE

This chapter is generated from the admin menu itself, so it lists every menu item.