Dibbla access

When someone at Dibbla enters your organization to help — when that happens, the two modes, what is recorded and what is not, how you are told, and how long the record is kept.

Sometimes the quickest way for us to help is to look at your organization the way you see it: open the app that fails, read its logs, check a setting. A small number of people at Dibbla can do that. This page describes exactly how it works, so you never have to wonder whether we have been inside your organization or what we did there.

The short version: every visit is a registered support session. The person has to choose a mode and write a reason before they get in, your owners and admins are told by email the moment it starts, and the visit — who, when, why and what they did — stays listed under Organization settings → Dibbla access in the console.

When we enter

We enter your organization to give support at your request — when you or someone in your organization asks us for help.

Every entry, without exception, requires the person to choose a mode and give a reason first. Your owners and admins are notified by email, and the visit is listed under Dibbla access.

Only a few people at Dibbla can open a support session, and only those who need to for this work. They are bound by confidentiality, as described in the Data Processing Agreement.

Two modes: read only, and read & write

Before the session starts, the person chooses a mode and writes the reason — in words that you will read. There is no way in without both.

• Read only — they can see what an owner sees: your apps, deployments, logs, settings, databases and workflows. Every request that would change something is refused by the platform, not just hidden in the interface.
• Read & write — they can also make changes, for example redeploy an app, change a setting or update a secret.

A read-only session can be raised to read & write in place when it turns out that something needs fixing. The raise is its own registered step with its own time and, when given, its own reason, and you are notified of it just like the start. There is no way back down: to go from write to read, the session ends and a new one starts.

A session ends when the person leaves, switches organization or signs out — and after 4 hours at most. When it ends, it ends everywhere: no copy of its login keeps working.

What is recorded

For every support session, your organization keeps a record of:

• Who — the person’s name and email address.
• When — when it started, when it ended and why (left, switched organization, signed out, or reached the 4-hour limit).
• Mode and reason — the mode it started in and the reason given.
• Raised to write — when, by whom and with which reason, if the session was raised.
• Every change they made or tried to make — each request that would change something, including the ones the platform refused in read-only mode. The console turns the common ones into plain sentences, such as “Changed secret DB_URL in app shop” or “Deployed app shop”, and shows the rest as the request itself.
• What they opened — which apps and parts of the console they looked at, such as an app, its secrets or the member list, with the first and last time.

The record names things — the app, the secret, the setting — but never contains a value or a body: no secret values, no file contents, no data from your database.

What is not recorded

The record covers everything a person does inside your organization during a support session — in the console, through the API and in your apps. It does not cover:

• Every single read. Reads are recorded per area opened, not per page view or per log line.
• Operational access to the infrastructure. The people who run the platform can reach the servers, the Kubernetes cluster and the databases underneath it directly, to keep the service running, restore it after an incident or carry out a deletion. That access is restricted to authorized Dibbla personnel and governed by the Data Processing Agreement, but it is not a support session and does not appear under Dibbla access.
• What your own team does. Dibbla access is about Dibbla. Your members’ own actions are not listed there.

How you are told

Every time a support session starts, and every time one is raised to write, each owner and admin of the organization gets an email with who entered, the mode, the reason and a link to the record. One email per event — three visits are three emails, never one summary.

You can also send these notices to a Slack channel or any other destination by subscribing it to org.support_access.* (see Notifications). Each owner or admin can unsubscribe from their own email; once turned off it is never turned back on for them.

Where to see it

In the console, open Organization settings → Dibbla access. Owners and admins see every support session in the organization, newest first, with an Ongoing badge on one that is still open. Expand a session to see what was changed and what was opened.

Developers and viewers do not see the tab. If you want them to know, add them as admins or route the notices to a channel they read.

How long the record is kept

The record is kept for as long as your organization exists, and at least 12 months. You cannot delete it, and neither can the person who made the visit — that is what makes it worth trusting.