Liquibase Secure server controls who can do what through four things: users, the groups they belong to, the permission templates assigned to those groups, and any customizations you make to a single assignment. This page explains how they fit together and how the server works out what a person is allowed to do.

Users and groups

Each team member registers in the web application with an email address and password. Permissions are not granted to people directly in normal use. They are granted to groups, and a person receives whatever their groups allow.

A Customer Admin can create, rename, and delete groups, and add or remove members. A user can belong to several groups at once.

• A group cannot be deleted while it is the sole owner of anything. The server lists what it owns and offers to transfer ownership first.

• Service principals are not group members. They are scoped per project instead.

• Two groups exist from the start and neither can be renamed or deleted. Administrators holds the workspace administrators and carries the Customer Admin template, so the first person in it can do everything. Pending holds users awaiting assignment and can never be granted permissions, so a user who arrives without an invitation has no access until you place them.

Permission templates

A template is a named bundle of permissions with a fixed scope. Liquibase ships six, and they cannot be renamed or deleted. You change what a group gets by customizing its assignment, not by editing the template. The Permission templates page lists all six with their scope and how many groups and users hold each.

The Permission templates page shows each template's full permission list, and how many groups and users hold it.

Assignments and scope

Giving a group access means assigning it a template against one or more targets. That pairing is an assignment, and its targets are a single list you can edit later. Adding or removing a project does not require recreating the assignment, and anything you have customized on it stays attached.

Scope resolves downward, never upward. A workspace assignment reaches every project and connection in that workspace. A project or connection assignment reaches only the targets named in its list.

Note: A pipeline is reached through its project, so a project assignment covers that project's pipelines alongside its connections, changelogs, and operations. A pipeline is never an assignment target in its own right.

Note: A permission check that names no resource matches nothing and is refused. Access is always evaluated against a specific workspace, project, or connection.

Customize what a template grants

You can customize a single assignment without touching the template. Open the group's access list, choose an assignment, and the editor opens as Customize followed by the template name. Add permissions beyond the template's bundle, remove permissions it grants, and read the result in a live preview that labels each permission Template or Added.

A customization follows its assignment's target list, so it applies to every target in that list and keeps applying as you add or remove targets.

Because templates keep their own definitions, your customizations survive a template upgrade. If a later version of the template introduces a permission you had already removed, the removal takes effect against it.

Note: Removing a permission on one assignment cannot take it away from someone who is granted it elsewhere. Permissions combine most-permissively, so a removal can look like it did nothing when a broader assignment still allows it. This is expected. Use a direct deny when you need to override a grant. A deny does not apply to an administrator, so it cannot narrow what one can do.

Ownership

Whoever creates a project, connection, or changelog becomes its owner. Both users and groups can be owners, and an item can have several.

An owner can view, edit, archive, restore, and delete the item they own, and manage who else owns it. Those actions apply even when the owner's template grants none of them, which is what lets the person who created a connection keep working on it without a workspace-wide template.

Owning a project also lets you view the connections and changelogs inside it, and the operations run in the project along with their database changes, policy checks, drift, and AI analysis. Owning a connection does the same for the operations run against that connection. Owning a changelog does not, so a changelog owner does not see the operations that used it. Each of these is a read on its own rather than a cascade of ownership. You do not become the owner of what you can see, you cannot change it, and you cannot manage who owns it. It also means a project owner can attach only connections and changelogs they can already see.

Note: A drift or diff run has no changelog, so it belongs to every project that holds the connection it ran against. Anyone who can see the operations in one of those projects, including that project's owner, can see the run.

Ownership widens what someone can do rather than overriding the rules around it. It is combined with templates and customizations in the same baseline, so a direct deny still contains an owner and a direct grant still restores.

An item cannot be left without an owner. When only one owner remains, removing it is refused until another is added. The same block applies to the people who own things, so a user who solely owns something cannot be deactivated until those items are transferred.

Review who has access

Two views answer the question a compliance review asks, which is not what can I do but who else can.

• Project access lists every group, user, template, and customization granting access to a given project.

• Entity access, opened from any item's detail page, lists the direct grants and denies on it, along with its owners.

Reading these views needs a permission separate from the one that lets someone use a project, and the Customer Admin and Security Reviewer templates are the two that carry it. Someone working on a project every day can therefore be unable to see who else has access to it. That is deliberate, not a gap in their access.

Note: When a capability is switched off by licensing, the grants and customizations that referred to its permissions are kept rather than deleted. They stop having any effect and appear in these views marked as belonging to a disabled capability. Switching the capability back on restores them without anyone re-creating them.

How effective permissions are worked out

For each assignment that applies to the resource being checked, the server takes the template's permissions, then applies whatever that assignment's customizations add or remove. It combines the results of every applying assignment, keeping the most permissive outcome.

Direct grants and denies are evaluated on top of that baseline, in a fixed order:

• An administrator is never denied, whatever route the deny takes.

• A direct grant wins over everything, including a direct deny.

• A direct deny overrides the template and customization baseline.

• The baseline applies when there is no direct grant or deny for that permission.

So the practical rule is that group membership widens what someone can do, and only a direct deny narrows it. It cannot narrow anything for an administrator.

Note: Denying the Administrators group, or denying an administrator by name, is refused when you save it. A deny on an ordinary group that an administrator belongs to is saved and applies to every other member of that group, but has no effect on the administrator.

The exemption is applied when a deny is read rather than when it is written. Adding someone to the Administrators group makes an existing deny stop applying to them, and removing them makes it apply again. A direct deny therefore cannot contain a resource from everyone, because it never contains it from an administrator.