2026-08
Permissions, SSO, alerting and an integrations registry
The release that makes the system fit a large organisation: levelled roles and permissions, OIDC single sign-on, an alert rule engine, and an integrations registry with encrypted secrets.
- Published
Highlights
- Levelled roles and permissions — read, edit, manage — instead of flat toggles
- OIDC single sign-on, end to end
- An alert rule engine with channel dispatch and permission-filtered delivery
- A database-backed integrations registry with encrypted secrets
- Global search, API access tokens and in-product API documentation
This release is less about coordination and more about what it takes for a system like this to sit inside a large organisation over time.
Levelled permissions
The permission model moved from flat toggles to levels: read, edit and manage, as a chain. A higher level includes the ones below it, so it is not possible to end up with someone holding manage rights without read rights.
Single sign-on
Full OIDC support, including group-to-role mapping.
Alerting
Rules defined by an administrator, dispatched to channels, and filtered by the recipient's permissions. That filtering is not cosmetic: an alert revealing the existence of a system the user is not permitted to see is a small disclosure.
Integrations registry
Connection settings for external systems moved out of a configuration file and into a database-backed registry, with secrets encrypted at rest. An administrator can add a connection and test it without access to the server.
Search and documentation
Global search across the system, and API documentation served from inside the product. The latter is a requirement in a disconnected environment, where you cannot point anyone at an external documentation site.
[VERIFY] — versions here are calendar-based (YYYY-MM) and name the month the scope closed. If a different numbering is already in use with customers, align to it before publishing.