What is Custom Policy Check?
Definition
Built-in Policy Checks cover common risks, dropping a table without a rollback, granting overly broad privileges, but every organization has requirements a generic tool can't anticipate: internal naming conventions, industry-specific data handling rules, or checks tied to a particular compliance framework. Custom Policy Checks let a team encode exactly those requirements as enforceable rules rather than as guidelines someone has to remember. Custom checks can often be written using scripting languages like Python for validations too specific or complex for a simple configuration option, giving teams the flexibility to check almost anything about a proposed change before deciding whether to allow it.
Why Custom Policy Checks matter
No default rule set can anticipate every organization's specific requirements. A financial services company might need a check that no ChangeSet touches a specific set of regulated tables without a named approver; a healthcare company might need a check enforcing a particular data masking pattern. Custom Policy Checks are what let a generic Policy Checks framework actually reflect an organization's specific risk profile instead of only its most common, generic ones, without waiting on a vendor to add support for a niche internal requirement.
How Custom Policy Checks work
A Custom Policy Check is defined the same way as a built-in one, as a rule a proposed change is evaluated against before it's allowed to deploy, but the logic itself is written by the organization rather than shipped as a default. For validations too complex for simple configuration, custom checks can be written as scripts, commonly in Python, giving teams the ability to inspect a change's specific details and apply whatever logic actually matters to their situation. A custom check can inspect anything available about the ChangeSet, its author, its target objects, or its Change Type, before deciding whether it should pass.
How Liquibase helps
Liquibase Policy Checks support custom checks alongside the built-in library, so an organization isn't limited to generic defaults when its actual risk profile calls for something more specific. Custom checks can be grouped into packages alongside built-in ones, enabled or disabled per environment or project, giving teams fine-grained control over exactly which standards apply where, rather than a single all-or-nothing policy set applied uniformly everywhere. Documenting why a custom check exists, not just what it does, helps future maintainers understand whether it's still relevant as the organization's standards evolve, rather than leaving a rule in place indefinitely without anyone remembering its original purpose.
