Security and Data Handling

What the platform stores, how tenants are isolated, what your administrators control, and what is recorded.

This page describes the security controls you administer and the data the platform holds, so your IT and privacy teams know what they are signing up for.

For our published security and privacy posture — encryption, compliance, and data processing commitments — see the Security page, or write to privacy@optimal-workforce.com.

What the platform stores

Optimal Workforce is designed to work on aggregate operational data, not on records about individual people.

What is stored:

Geographic areas — Canadian forward sortation areas (the first three characters of a postal code, such as M5V) and the regions you group them into.
Metrics per area — counts and rates such as active clients, active employees, visits, hours, and completion rates.
Your configuration — regions, alert thresholds, optimization runs and their results, saved preview scenarios, and generated reports.
User accounts — name, email, and role assignments.

What is not stored:

Client or employee names, addresses, phone numbers, or identifiers
Full postal codes — only the three-character area is kept
Any clinical or health information
Anything at an individual person's level of granularity

When you connect an API source, aggregation happens as part of the sync: the platform reads what it needs to compute the counts and does not retain the underlying records. When you upload a CSV, the file must already be aggregated — the upload wizard actively scans for columns that look like personal information and warns you. See CSV Upload.

Tenant and team isolation

Access is enforced in the database, not only in the interface. Every query runs under the identity of the person making it, and rows are filtered to the accounts they have a membership in. A user who is not a member of a team cannot read that team's data by any route — including by manipulating a URL.

The organization and team levels are enforced separately. See Administration for what each role can do.

Authentication controls you own

Single sign-on

The strongest control available to you. With SAML SSO registered, access is governed by user and group assignment in your Microsoft Entra tenant — including revocation. See Single Sign-On.

Multi-factor authentication

MFA uses a time-based one-time code from an authenticator app. Once a user has enrolled a factor, they are challenged for it at every sign-in, and the requirement is enforced on the data itself, not just at the sign-in screen.

MFA enrolment is per user

There is no organization-wide setting that requires every member to enrol. If your policy mandates MFA, either enforce it upstream through Entra Conditional Access and use SSO, or verify enrolment with your users directly. Do not assume it is on.

Sessions

Sessions are short-lived and refresh in the background while a user is active. Signing out ends the session. Removing a user from Entra stops future sign-ins through SSO; to cut off an existing session immediately, also remove their team and organization memberships.

What is recorded

The platform records an activity trail for membership and access changes:

Event	When it is recorded
Sign-up	A new user account is created
Membership joined	Someone is added to a team
Membership left	Someone is removed from or leaves a team
Role changed	A member's team role is changed
Invitation sent	A team invitation is issued

Separately, data operations are traceable through their own history: sync runs are recorded with their outcome, CSV uploads are retained as batches, alert violations are kept as a history you can chart, and every optimization run keeps the exact configuration it was given.

What is not in the activity trail

Registering or removing a single sign-on provider, changing organization-level roles, and changing shared vendor credentials are not currently written to the activity trail. Those records show who last changed them, but there is no event history to review. If you need an auditable log of those actions, raise it with your Optimal Workforce representative and keep your own record of changes in the meantime.

Getting data out

Data leaves the platform through explicit, per-artifact exports:

CSV from the Data Editor, the Preview sandbox, and any completed optimization run
PDF from the Reports area

There is no self-serve bulk export of an entire account. If you need one — for a data subject request, a migration, or an archive — contact your Optimal Workforce representative.

Offboarding a user

In order:

Unassign them in Microsoft Entra, if you use SSO. This is what actually stops them signing in.
Remove them from each team at /home/<team>/members.
Remove them from the organization at Manage Tenant → Members.

Removing an organization membership alone does not remove team access. Removing team access alone does not stop them signing in.

Deleting data

A team can be deleted from its Settings page when deletion is enabled for your deployment. This removes its data source configuration, regions, alerts, runs, and reports.
A personal account can be deleted by its owner from /home/settings when account deletion is enabled.

Both are irreversible. For deletion requests that need a record, or for anything covering the whole organization, contact privacy@optimal-workforce.com.

Questions to raise with us

These are reasonable things for an IT or security team to ask about, and are not self-serve today:

Enforcing MFA across every user in the organization
An audit log covering SSO, organization roles, and credential changes
Bulk account data export
Customer-managed encryption keys or a secrets vault integration
Data residency and retention commitments for your contract