When things go wrong

This page covers the specific failure modes this documentation could actually verify against the running product, what causes them, what you’ll see, and what to do. It does not cover the machine underneath the product (backups, the audit log, reading logs).

“Nothing I do in Deliver seems to work”: no active baseline

Symptom: every attempt to change the plan fails, with no obvious reason shown.

Cause: an instance with no active baseline refuses every plan-changing write. This should not happen on an instance set up the normal way, because setup creates a working baseline. It is a real risk only if your data came from somewhere else, such as a bare database restored without its setup. Check Admin, Settings for an active baseline, and create one there if there is none. See Baselines.

An account with no linked person

Every login account is now required to have a linked plan person, a migration enforces this at the database level, not just in the screen that creates a new account. If your instance is upgrading from a version old enough to predate this rule, the upgrade migration will:

1. Try to fix it automatically first. Any account whose email matches an existing, not-yet-claimed plan person is linked to it automatically, no admin action needed for the common case of an account and a person that were always “the same person,” just never formally linked.
2. Refuse the entire upgrade if any account is still unlinked afterwards. The migration will not proceed, and will not silently drop or disable the account, it fails loudly, naming every affected email address in the error message, so you know exactly what to fix.

What to do: for each named account, either link it to the correct plan person from Admin → People and access, or remove the account, before attempting the upgrade again. There is no way to make the upgrade proceed with an unlinked account left in place, this is a structural rule, not a warning you can dismiss.

A licence that has lapsed

See Licensing for the full picture. In short: nothing breaks, and no data is at risk. Expiry starts a 30-day grace period during which everything works exactly as before; once that passes, the instance becomes read-only, everyone can still read and export everything, nothing is deleted, and no new change is accepted. A banner on every screen says so, so nobody has to work it out from a refused Save.

If people report “it won’t let me save anything”, check the Licence page first: a read-only refusal comes back as a message naming the lapse, not a permission error. Install a renewed licence file from the account menu’s Licence page and editing resumes immediately, no restart, and nothing that was typed in the meantime was lost from the record, because nothing was written. Installing a licence is itself always allowed while read-only; a lapse is never a lockout.

An unentitled feature and why it looks the way it does

See Licensing. The short version, if you’re trying to work out whether something is broken or simply not licensed: an Admin always sees exactly which edition a missing feature needs, right on the screen that would otherwise show it, or on the Licence page. Nobody else ever sees the feature exist at all. If a non-Admin reports a “missing” feature and can’t tell you what edition it needs, check the Licence page yourself before assuming something is actually broken.

A migration refuses to run

Migrations apply automatically on server boot, in order, and a migration that finds the database in a state it can’t safely handle refuses the whole boot rather than proceeding partially. The account-linking refusal described above is one example. If a boot fails with a migration error, read the message in full, it’s written to name the fix, not just the symptom, before looking anywhere else.

If a migration fails, the instance is down, not running on the old schema

Migrations run at startup, and a failure is not caught: the process exits before it starts listening. There is no fallback to serving traffic on the previous, unmigrated schema, and no partial start. A failed migration means the instance is fully down until the underlying problem is fixed (or the previous image is reinstalled against a restored backup), not a degraded-but-running state. Because each migration also runs in its own transaction, app.db itself is left exactly as it was before the failed attempt , nothing to repair by hand, but nothing serving requests either.

Disabling an account

An account can be disabled. Go to Admin, People and access and use Disable on the account. Disabling blocks sign-in immediately, including for a session already open, and leaves every role grant untouched, so re-enabling restores the person exactly as they were. You do not need to revoke roles to stop someone signing in, and you should not, because that destroys the grant history. The last enabled administrator cannot be disabled. Every disable and re-enable is written to the audit log.