Security and data isolation
Organisations are isolated from each other and access is scoped by project, role and action. We work to an SLA and support LDAP and SSO sign-in.
Organisations are isolated
An organisation is a separate data space. Projects, cases, runs and members belong to it and are invisible outside it.
Data belongs to an organisation
Every record has an owner. A request into another organisation fails the access check rather than merely hiding rows in the interface.
Several organisations per person
An agency or contractor keeps clients apart and switches between them without mixing anything.
Entry by invitation only
A member appears through an internal invitation or an invitation link issued by an organisation admin.
Roles and rights
A right is checked against a specific action, not a whole section. Preset roles can be edited or replaced with your own.
- Preset roles
- Admin, manager, lead, tester and guest. The set of rights on each role can be changed.
- Over sixty rights
- View, create, update and delete separately for cases, plans, runs, dashboards, environments, configurations, roles, import and export.
- Custom roles
- An organisation admin builds a role around the team process: a reviewer without the right to delete cases, for example.
- Access per project
- Project membership is granted separately: working in one project does not open the neighbouring ones.
Sign-in, tokens and reports going out
Authentication is delegated to Keycloak, and anything that leaves the system is switched on by an explicit action.
SSO through Keycloak
Sign-in runs on OAuth2 and OpenID Connect. In your perimeter Keycloak connects to your directory over LDAP or SSO.
API tokens
Automation gets its own token. It is listed and can be revoked without touching the person's account.
Report by link
A test run report can be opened by link without access to the system. Private or public is decided by the report author.
Where the data sits
Data is split between two places: a relational database and object storage. In your perimeter both of them are yours.
PostgreSQL
Cases, runs, results and change history are stored in the relational database.
S3 or MinIO
Attachments on run results, screenshots and logs sit in object storage, separate from the database.
Your own perimeter
With an on-premise install the database, the storage and the AI loop all stay inside the network.
Change history
Who changed what can be reconstructed without contacting support.
- Role and access log
- Role creation and edits, permission changes, ownership handover, user activation and deactivation. Author, time, old value and new value are recorded.
- Step revisions
- Case steps are stored as revisions: a run points at the version of the steps it was executed against.
- Case review
- Field changes are visible line by line, together with comments and reviewer statuses.
- Test data history
- A test data record keeps an event history and shows which cases use it.
Let us go through your access model
We will show how your roles and projects map onto the system and answer your security team. Response and recovery terms are fixed in the contract.