What OneOS reads
History from the tools your admin connects: past tickets, Slack, Jira, GitHub, Datadog and Google Cloud logs. A tool that isn't connected adds nothing, and its section stays empty.
Security
Security your review team can check.
OneOS reads sensitive history from your tools. Here is how access stays tied to your identity provider, how each customer's data stays separate, and how sensitive detail stays away from people who shouldn't see it. What we haven't published yet is marked as such.
Okta SAML is live. Google Workspace and Microsoft Entra are planned.
In use today
Planned
Not yet published
Click any row to jump to its section.Status as stated on this page. Nothing here is a certification.
Sign-in and access
Access comes from your identity provider.
Admins sign in through SAML single sign-on. Okta is supported today. SCIM provisioning adds and removes people automatically, so when someone leaves your company, their OneOS access ends with their identity-provider account.
OktaSAML single sign-on and SCIM provisioning.Live
Google WorkspaceSign-in for admins. Not available yet.Planned
Microsoft EntraSign-in for admins. Not available yet.Planned
Support reps never sign in to OneOS. It runs inside Zendesk or HubSpot, under that tool's own sign-in. Only admins use the OneOS console.
Fictional workspace, real behaviour. Roles can follow your Okta groups.
Tenant isolation
Your data stays yours.
Every customer's data is kept separate, and closed off by default. If OneOS can't tell for certain which customer a request belongs to, it refuses the request rather than guessing.
Quellbrook workspace
- #5230 Scheduled report PDFs arrive empty
- #4977 Weekly report PDF blank
Another customer's workspace
Closed off. Not visible from here.
Role-based views
Sensitive detail goes only to the roles that need it.
Support reps see a masked summary. DevOps and engineering roles see technical detail. Choose a role and watch the same case change.
OneOS#5230
Scheduled report PDFs arrive empty
Ines M. · Quellbrook · Seen by a support rep
Roles are set in the admin console. Your identity provider can drive them.
Data handling
What we can state today, and what we haven't published yet.
Where a security page would usually print a number or a badge, we leave a gap until we can stand behind it.
Credentials for your tools
Encrypted at rest and scoped to your workspace. We ask for read-only access where the tool allows it. An admin can remove a credential at any time.
JiraConnected per workspace••••••••••••
Slack replies and private channels
- Replies are recorded from the escalation threads OneOS started.
- A message taken from a private channel is stored separately, and shown only to DevOps and engineering roles.
Nothing invented
Every line OneOS shows links to the record it came from: a reply, a message, an issue, a log entry. Where nothing supports a section, it stays empty. There is no chat box.
Certifications
Shown here only once we hold them. No badge until then.
Hosting region
Hosting region: to be published.
Sub-processors
Sub-processor list: to be published.
Data retention
Retention periods: to be published.
Audit log
Every action is recorded.
Sign-ins, escalations, connection changes and admin actions are written to an audit log your admins can review. Pick an action and watch it land.
Audit log retention:to be published
Security review
Send us your questionnaire. We'll answer it directly.
Tell us what your review needs. Where we have the answer, you get it from a person. Where we haven't published it yet, we say so plainly.
Certifications, hosting region, sub-processors and retention appear on this page when we can publish them.