Documentation
Tenant setup
What to configure before your first real matter goes in, and how to verify that isolation works rather than take our word for it.
1. Provisioning
We create your tenant and issue an owner invitation and a set of API credentials. The tenant identifier is fixed at creation and appears in every record and every stored object path. It cannot be changed later, so it is worth choosing something that will still make sense to you in three years.
A sandbox tenant is issued alongside your production one. Use it for integration testing — it is isolated from production by the same mechanism as any other tenant.
2. Identity
Authentication is handled by our identity provider. You can either invite users by email with magic-link sign-in, or connect your own directory over SAML or OIDC.
- Connect your directory. Supply your metadata URL and we return the values to register on your side. Once SSO is active, email sign-in is disabled for your tenant so there is no second route in.
- Enforce multi-factor authentication at the tenant level rather than leaving it to each user. Do this before you invite anyone.
- Set up deprovisioning. Removing a user from your directory revokes their access at their next token refresh. Confirm this works before you rely on it.
3. Roles
Roles are carried as a JWT claim and enforced in the database, not only in the interface. Assign the narrowest role that lets someone do their job.
| Role | Scope | What it can do |
|---|---|---|
| Owner | Tenant-wide | Everything below, plus billing, SSO configuration, retention policy, and adding or removing administrators. |
| Administrator | Tenant-wide | Manage users and role assignments, read the tenant audit log, configure templates. Cannot change billing or delete the tenant. |
| Practitioner | Assigned cases | Create and manage cases, generate documents, and export. The working role for a fee earner or advocate. |
| Assistant | Assigned cases | Upload documents, enter case facts, and read drafts. Cannot delete a case or export a full audit trail. |
| Auditor | Tenant-wide, read only | Read audit logs and case metadata. Cannot read case file contents or generate documents. |
4. Retention
Set how long case material is kept after a case closes, and whether deletion is automatic or requires confirmation. Match this to the file retention policy your practice already runs rather than accepting a default. Audit entries are retained separately and are not removed by case deletion.
5. Templates
If you are using your own precedents, upload them before go-live. Templates are versioned, and each version is checked by the same document linter that runs on ours, so a template that would produce a malformed filing is rejected at upload rather than at generation.
6. Verify isolation before you trust it
Do not take the isolation guarantees on faith. Run these against your sandbox tenant:
- Request a case identifier that belongs to another tenant. You should receive an empty result, not a permission error — identifiers must not be probeable.
- Take a signed download URL and use it after its expiry. It should fail.
- Assign a user the Auditor role and confirm they can read the audit log but not the contents of a case file.
- Remove a user from your directory and confirm their access ends at the next token refresh.
- Perform an action, then confirm it appears in the audit log with the correct actor.
7. Go live
Move to the production tenant once those checks pass. Point your integration at production credentials, and keep the sandbox for testing future changes.
Related
Endpoint reference is in the API documentation. Security and procurement detail is on the enterprise page. Questions go through contact sales.