Security and the audit log
How tenants are isolated, what the audit log records, and the recovery paths that exist when somebody deletes the wrong thing.
Tenant isolation
Every query is scoped to one organization, in the application, and the database enforces the same boundary independently underneath — deny by default, on every table. Two layers rather than one, because a single application-layer bug should not be enough to cross a tenant boundary.
Permission checks run on the server before any operation, and are identical whether the request came from the dashboard, the mobile app, the assistant or the API. There is no privileged path that skips them.
The infrastructure detail — hosting, subprocessors, encryption, reporting a vulnerability — is on the security page, and the legal commitments are in the data processing agreement.
What the audit log records
Every operation that changes data writes an audit entry, server side, as part of the same path that performs the change. There is no way to mutate data without one, and that is a structural property rather than a habit — the writing happens in the layer all four surfaces go through.
Each entry records:
- What happened, as a named action.
- Who did it.
- When.
- Which record it affected.
- How it arrived — a person in the UI, the assistant acting on their behalf, an API key, or a scheduled job.
That last field is the one people find most useful in practice. A shift that changed at 3am was a scheduled job; the same change at 3pm was a manager, and the log distinguishes them without anybody having to reconstruct it.
Managers read it under Audit, filtered by person, action or date. Scheduled jobs appear as the manager they ran as, because they genuinely do run as a real manager rather than as a system superuser.
Retention is 90 days, or seven years on Business. One detail worth knowing if you ever change plan: the window only ever lengthens. Moving down from Business does not delete the history you already accrued — losing years of compliance evidence as a side effect of a billing change is not a thing that should be possible, so it is not.
Undo and recovery
Three separate safety nets, for three different mistakes.
- Undo in the week grid, for the edit you just made.
- Restore a wiped week — clearing a week is reversible for a period afterwards, and the restore puts every shift back exactly as it was. This is what makes wiping a draft you dislike a safe thing to do.
- Archive rather than delete an organization. Archiving takes it out of use and is reversible; the data stays.
Single sign-on
On Business, your team can sign in through your own identity provider over SAML 2.0 — Google Workspace, Okta, Microsoft Entra, OneLogin and anything else that speaks the protocol. We register your IdP, give you a provider ID, and an owner links it under Settings.
One behaviour to know about, because it is surprising and we handle it for you: an SSO sign-in creates a new account rather than logging into an existing one. Someone who has been using a password for a year would otherwise arrive as a stranger with no schedule and no history.
So when somebody signs in through your IdP, we match the verified email against your roster and move their membership — along with their profile, notifications and calendar feeds — onto the new account. Their shifts, requests and records come with them, because those belong to the membership rather than to the login.
The match is scoped to the provider your organization authorized. An identity provider can only claim people in the organization that registered it, never in anybody else's — which matters, because SAML places no restriction on what email address a provider may assert.
Personal data
A person's profile belongs to them and is deletable by them from their own account settings. Their employment records — shifts worked, hours, time-off decisions — belong to the organization that employed them and remain, because payroll and labour law require the employer to keep them.
That split is why removing somebody from your roster is a status change rather than a deletion. See Inviting and managing your team.
Your data is not used to train AI models. The assistant reads your organization's data to answer your questions and nothing leaves that boundary for training.
Common questions
- Can anybody edit or delete an audit entry?
- No. Entries are written by the server as part of the operation itself; there is no interface for editing them and no operation that produces one selectively.
- How long are entries kept?
- 90 days on Starter, Core and Pro; seven years on Business. If an organization moves down from Business, the history it already accrued stays — retention only ever lengthens, never shortens retroactively. For a permanent record beyond that, export periodically or subscribe a webhook.
- Does the audit log show reads?
- No — it records changes. Reading a schedule is not an auditable event; changing one is.
Related
Roles and permissions
Four roles — Owner, Admin, Manager, Employee — what each one can reach, and how the permission check actually works underneath.
API and webhooks
One RPC endpoint exposes every operation in the product, authenticated by a scoped org key. Outbound webhooks are signed and retried. Reference for both.
Plans and billing
Why the bill is per location rather than per employee, what each plan unlocks, how the trial works, and what happens when a payment fails.