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.