Liquid template language is an open-source templating language, created by Shopify, that uses objects, tags, and filters to display data and apply simple logic inside text. Low-code platforms embed it so builders can write conditions, calculations, and dynamic email content without full programming.
If you configure or maintain Onit apps, you will meet Liquid in the curly braces that appear in conditions, notifications, and field logic. Most expressions are short, and the core syntax takes an afternoon to learn. The risk lies in small mistakes in live workflows, so this guide covers the building blocks, how they show up in Onit, and the testing habits that keep changes safe.
What is the Liquid template language?
The Liquid template language is a simple, readable syntax for inserting data into text and applying logic, built from three parts: objects, tags, and filters. It was designed to be safe for non-developers to edit. Liquid is an open-source template language created by Shopify and in production use there since 2006, so its syntax is well documented. Templates still need care, since research estimated accumulated software technical debt in the US at about $1.52 trillion.
The three building blocks:
- Objects. Output data, written in double curly braces, such as `{{ request.status }}`.
- Tags. Add logic, written in curly braces with percent signs, such as `{% if request.value > 100000 %}`.
- Filters. Change how output looks, added with a pipe character, such as `{{ request.title | upcase }}`.
Everything else in Liquid builds on these three. Once you can recognize each one, most expressions become readable at a glance.
Where does Liquid appear in Onit configuration?
Liquid appears in Onit configuration wherever text or logic needs to change based on record data, such as conditions on fields, calculated values, and notification templates. Which contexts support Liquid, and which objects and filters are available, depends on your Onit version.
Places builders commonly look for it:
- Conditions. Showing or hiding a field, or deciding whether an action runs.
- Notifications. Inserting a requester’s name, a matter number, or a due date into an email.
- Calculated values. Building a title or reference from other fields.
Confirm the supported contexts in the App Builder documentation for your release before relying on Liquid in a new place. Where the platform offers a point-and-click option for the same job, such as a standard condition builder, prefer it for simple rules. Reserve Liquid for logic the standard options cannot express, which keeps most of the app readable to administrators who are not comfortable with the Liquid template language. The platform behind this is introduced in what Onit Apptitude is and what it is used for.
How do Liquid objects output data?
Liquid objects output data by placing a variable name inside double curly braces, so `{{ request.requester_name }}` prints the requester’s name. Properties are reached with dot notation or square brackets.
Dot notation such as `{{ matter.client.name }}` reads a nested property, and bracket notation such as `{{ matter[‘client’] }}` works where a name contains spaces or is built dynamically. The exact object and field names come from your app’s configuration, so check the field’s system name before writing an expression. A typo in a field name usually prints nothing, which is easy to miss in testing. Keep a short reference of the field system names used most often in your apps, such as requester, business unit, contract value, and due date. New builders spend less time guessing, and expressions stay consistent across workflows. When a field is renamed in configuration, search existing expressions for the old name before releasing the change.
How do Liquid tags add logic?
Liquid tags add logic by wrapping instructions in `{% %}`, so text or actions change depending on conditions, loops, or stored values. The most common tags are `if`, `unless`, `case`, `assign`, and `for`.
What each does:
- if / else. `{% if request.priority == “High” %}Urgent{% else %}Standard{% endif %}` chooses between outputs.
- case / when. Picks one branch from several values, useful for regions or contract types.
- assign. `{% assign threshold = 250000 %}` stores a value to reuse later in the template.
- for. Loops over a list, such as the approvers on a request.
The `unless` tag runs when a condition is false, which is a shorter way to write “if not”. Every opening tag needs its closing tag, such as `endif` or `endfor`. A missing closing tag is the single most common Liquid error, and it can stop a whole template from rendering. Indent nested tags in longer expressions, so each opening and closing pair is easy to match by eye.
How do Liquid filters change output?
Liquid filters change output by passing a value through one or more transformations after a pipe character, such as `{{ request.due_date | date: “%d %b %Y” }}` to format a date. Filters can be chained left to right, so `{{ request.title | strip | upcase }}` trims spaces and then capitalizes.
Filters builders use most:
- Formatting. `upcase`, `downcase`, and `capitalize` adjust text.
- Dates. `date` formats a timestamp for an email or title.
- Defaults. `default` supplies a fallback when a field is empty, such as `{{ request.region | default: “Not specified” }}`.
Platforms often add their own filters on top of standard Liquid. Use only filters documented for your Onit version, and test any platform-specific filter, such as one that looks up a value in an administrator list, before using it in production.
How do comparison operators work in Liquid conditions?
Comparison operators in Liquid conditions compare values inside `if`, `unless`, and `case` tags, using symbols such as `==`, `!=`, `>`, and `<`, combined with `and` and `or`. The result decides which branch runs.
Points that catch new builders:
- Text versus numbers. Comparing a number stored as text can give unexpected results, so confirm each field’s data type.
- Evaluation order. When mixing `and` and `or`, Liquid evaluates from right to left, so split complex conditions into simpler ones.
- Empty values. A blank field compares as nil, so test each condition against records where the field is empty.
Check which operators your platform’s Liquid implementation supports, including text-matching operators such as `contains`, before relying on them. Conditional design is covered in why basic automation fails without advanced conditional logic.
How should Liquid be used in Onit email templates?
Liquid in Onit email templates should insert record data into subjects and bodies, with defaults for empty fields and conditions for content that only some recipients need. Every template should read correctly even when optional fields are blank.
Write the template in plain language first, then add Liquid only where data must change. Use `default` for fields that may be empty, so a notification never reads “Dear ,”. Keep conditional blocks short, and preview each template with a real record before saving. If a template needs more than three or four conditions, consider separate templates for each case. Email design is covered in why basic email automation alone is not enough for enterprise platforms.
How do you test Liquid in Onit before release?
You test Liquid in Onit by running each expression against real records in a non-production environment, including records with missing values, unusual characters, and every branch of each condition. Nothing written in Liquid should reach production untested.
Test cases to include:
- Empty fields. Confirm defaults appear and nothing breaks.
- Every branch. Trigger each `if`, `else`, and `case` path at least once.
- Rendered emails. Send test notifications and read them as a recipient would.
A small change may need only five to ten cases, while a new template may need twenty or more. Record each case and its result, so the next release can reuse them. Release practice is covered in release management on configured legal platforms.
How do you keep Liquid maintainable?
Liquid stays maintainable when expressions are short, named clearly, documented, and reused where possible. Six months later, someone else should understand each expression without the original builder.
Assign meaningful variable names, such as `approval_threshold` in place of `x`. Add a short note in the configuration explaining what each non-trivial expression does. Keep thresholds and lists in one place so a policy change means one edit. Keep a log of Liquid changes with the date and the reason, which shortens troubleshooting when a rule behaves unexpectedly. Documentation practice is covered in why code without documentation is a ticking time bomb.
Conclusion
The Liquid template language gives Onit builders a readable way to add logic and dynamic content to apps. Learn the three building blocks of objects, tags, and filters, confirm which objects and filters your Onit version supports, write defaults for empty fields, and test every branch before release. Short, documented expressions keep your workflows easy to change as requirements grow.
How Basla can help
Basla provides delivery teams for Onit implementation, covering legal technology consulting, business analysis, Apptitude app configuration, Liquid conditions, calculations, and email templates, testing, release management, documentation, and post-go-live support. The team writes and documents expressions to your standards, then tests every branch before release.
On a Contract Lifecycle Management rollout, Basla created and executed more than 1,000 test records, and the delivery team doubled in size to meet a compressed implementation timeline.
Frequently asked questions
What is the Liquid template language?
The Liquid template language is an open-source templating language created by Shopify. It uses objects, tags, and filters to display data and apply logic inside text.
What do the curly braces mean in Liquid?
Double curly braces `{{ }}` output a value, and curly braces with percent signs `{% %}` hold logic such as conditions and loops.
What is a Liquid filter?
A Liquid filter changes how a value is displayed, added after a pipe character. For example, `{{ title | upcase }}` prints the title in capital letters.
Does Onit use Liquid?
Onit configuration can use Liquid for conditions, calculated values, and notification templates. Supported contexts, objects, and filters depend on your Onit version.
How do I avoid errors in Liquid expressions?
Close every tag, confirm field names and data types, add defaults for empty fields, and test each branch in a non-production environment before release.
Can non-developers learn Liquid?
Non-developers can learn the core of Liquid quickly, since it uses a small set of readable building blocks. Complex expressions still benefit from review by an experienced builder.
*This article is provided for general information only and does not constitute legal advice. Basla Solutions provides legal technology implementation and support services and does not practice law.*