Support, restores and exits

Raising something

Include these four things and most issues are answerable on the first reply:

1. Your version. curl -s https://yourhost/api/health/version, or Admin, Licence in the product.
2. What you did, and what happened instead. Including the exact wording of any error.
3. When it started, and what changed immediately before. This solves it more often than anything else.
4. Whether it affects everyone or one person. A single account behaving differently is almost always a role or a module, not a fault.

Support level follows your plan. Core is email; Standard adds business hours; Advanced and Enterprise are covered in your agreement, along with any service credits.

Vendor access

Access to your deployment is off by default, time-bound when granted, and audited. Every action a vendor engineer takes appears in your own audit log alongside everything else, attributed to them.

You can disable it outright from Admin, Compliance. With it disabled, we cannot reach your data at all, which also means some kinds of support become “here is what to look for” rather than “we looked”. That is a legitimate trade and some schools make it deliberately.

See compliance answers.

Restores

Backups are taken for you and tested. To request a restore, tell us:

• Which deployment, if you have more than one.
• The point in time you want to go back to.
• Whether you want the whole database or a specific extraction. Restoring everything to yesterday discards today. Sometimes what you actually want is one table, or one record, pulled out of a backup and put back.

We will confirm what will be lost before doing anything. A restore is one of the few operations where the confirmation matters more than the speed.

For self-hosted deployments, restores are yours. See backups and restore.

Getting your data out

You do not need to ask. Admin, Backups exports a portable per-tenant copy at any time. It is a normal feature.

The export contains every record for your tenant. Connector credentials are included but encrypted, so an export restored elsewhere needs the matching SECRETS_MASTER_KEY. If you are leaving for a self-hosted install we hand that over as part of the move.

Moving between hosting models

Both directions are supported and follow the same shape: an export, a provision, an import, a DNS change.

Managed to self-hosted:

1. You provision a server and install Plugboard. See install it yourself.
2. We export your deployment and hand over the export plus SECRETS_MASTER_KEY.
3. You import, start, and confirm you can sign in and that connectors still test successfully. That last check is what proves the secrets decrypted.
4. Add the new SSO redirect URI at your identity provider before cutover, keeping both registered during the change.
5. DNS moves. We keep the old hostname resolving for a while so links already sent keep working.
6. Your licence continues. Self-host rights are part of the Enterprise tier or negotiated separately.

Self-hosted to managed: the same in reverse, and easier, because we provision the target.

Between regions: the same again, within managed hosting. Tell us early. The DNS and identity provider changes have lead times that dwarf the data movement.

The thing people forget in every direction is the identity provider. Redirect URIs are absolute, and a cutover that changes the hostname without changing them locks everyone out of SSO at the worst moment.

If we go away

Self-hosted deployments keep running. The licence check is local and offline, so there is no phone-home that can fail closed.

Managed customers can export at any time without our involvement, and the export is a product feature, not a support process.

Incidents

Severity levels, what happens in the first fifteen minutes, and when customers and regulators are told are covered in incidents.

The short version: you are told about anything affecting your deployment, with what we know rather than with a holding statement, and the status page is not the only channel.