Advanced Liquid for Onit: Loops, Capture, and Filters

Advanced Liquid is the set of Liquid techniques that go beyond simple output and conditions: capturing text into variables, looping over lists, counting, chaining filters with parameters, and filtering collections before you loop. In Onit, these techniques power richer email templates, calculated titles, and rules that work across lists such as approvers or line items.

They also raise the stakes. A loop that runs on every record, or a captured string that breaks when a field is empty, can slow a workflow or send a confusing notification to hundreds of people. This guide covers each advanced construct, how to use it within Onit, and the performance, security, and testing habits that keep expressions reliable. It assumes you already know objects, tags, and filters.

What does advanced Liquid add beyond the basics?

Advanced Liquid adds ways to build and reuse values, repeat logic across lists, and transform data in several steps, so templates can handle real-world records with many related items. The building blocks stay the same objects, tags, and filters, and the public Liquid documentation lists every tag and filter, from control flow and iteration to filters such as date, sort, and where. Test advanced templates carefully, since research put the cost of poor software quality in the US at $2.41 trillion in 2022.

The main techniques:

• Capture. Build a string from text, variables, and logic, then reuse it.
• Loops. Repeat a block for each item in a list, with limits and early exits.
• Counters. Number items or track how many times something occurred.
• Filter chains. Apply several transformations in order, some with parameters.
• Collection filters. Narrow, sort, and clean a list before looping over it.

Platform support varies, so confirm which tags and filters your Onit version supports before using one in production. The platform is introduced in what Onit Apptitude is and what it is used for.

How does the capture tag build complex text?

The capture tag builds complex text by collecting everything between `{% capture name %}` and `{% endcapture %}` into a new string variable, including literal text, other variables, and the output of conditions. The variable can then be used anywhere later in the template.

Where capture helps in Onit templates:

• Reusable subject lines. Build a subject once, such as matter number, client, and priority, and use it in several places.
• Conditional sentences. Capture a sentence that changes with the record’s status, then insert it into the email body.
• Reusable link text. Capture a record link with its label once, then insert it in both the body and the footer.

Keep each captured block short and give it a descriptive name, such as `approval_summary`. Long captures with nested conditions become hard to read, so split them into two or three smaller captures. Remember that captured values are text, so convert them before using them in numeric comparisons.

How do loops work in Liquid?

Loops in Liquid run a block once for each item in a list using `{% for item in list %}` and `{% endfor %}`, with parameters such as `limit` to cap the number of iterations and `break` and `continue` to control flow. They are how one template handles a list of any length.

Loop controls to know:

• limit. `{% for approver in request.approvers limit: 5 %}` stops after five items, which keeps emails readable.
• break. Exits the loop early, for example once the first pending approver is found.
• continue. Skips the current item, for example approvers who have already signed off.

Always plan for an empty list. Pair the loop with a check, or with the `else` branch that some Liquid implementations support for empty loops, so the template prints a clear message when there is nothing to list.

How do counters work in Liquid?

Counters in Liquid are created with `{% increment name %}`, which starts at 0 and rises by 1 on each call, and `{% decrement name %}`, which counts down. They are useful for numbering items or tracking occurrences within a template.

Counters suit simple numbering, such as listing outstanding items as 1, 2, 3 in a reminder email. For anything more involved, such as totals or values you compare later, assign and update a variable explicitly. That makes the intent clearer to whoever maintains the template, and confirm in testing how counters behave in your Onit version.

How do you chain filters with parameters?

You chain filters with parameters by adding several filters after the pipe character, each applied left to right, with parameters given after a colon, such as `{{ request.due_date | date: “%d %b %Y” | upcase }}`. The output of each filter becomes the input of the next.

Chaining rules worth following:

• Order matters. Trim or replace text before changing case, and format dates before adding them to strings.
• Defaults early. Put `default` near the start of the chain so later filters never receive an empty value.
• Keep it short. Three or four filters in one chain is usually the readable limit.

If a chain grows longer, assign the intermediate result to a named variable. Reviewers can then check each step separately.

How do you filter collections before looping?

You filter collections before looping by applying list filters such as `where`, `map`, `sort`, `compact`, and `uniq` to narrow and clean the list first, then looping over the smaller result. This replaces conditions inside the loop and reduces processing.

What each filter does:

• where. Keeps only items matching a property, such as approvers with status “Pending”.
• map. Extracts one property from each item, such as just the approver names.
• sort, compact, and uniq. Order the list, remove empty values, and drop duplicates.

Filtering first keeps loops simple and fast, since a condition inside a loop runs once per item. Confirm which list filters your Onit version supports, since availability varies between Liquid implementations. Conditional design is covered in why basic automation fails without advanced conditional logic.

How do platform-specific filters and lookups work in Onit Liquid?

Platform-specific filters and lookups in Onit Liquid extend standard Liquid with functions tied to the platform, such as reading a value from an administrator-maintained list or building links to records. Their names, parameters, and behavior must be confirmed for your Onit version.

Treat every platform-specific filter as something to validate. For a lookup, confirm the list name, the column searched, and the column returned, and test what happens when no match is found. Keep lookup lists owned and maintained, since a rule that reads a stale list routes work to the wrong person. Document each platform filter used, with an example of its expected output. When Onit releases a new version, re-run the tests for every template that uses a platform filter, since behavior can change between releases even when the name stays the same.

How do you keep advanced Liquid fast and secure?

Advanced Liquid stays fast and secure when collections are filtered before loops, complex conditions sit outside loops, and expressions never display data the recipient should not see. Where Liquid runs, and under which permissions, depends on the platform.

Practical habits include setting loop limits on lists that can grow, avoiding nested loops over large lists, and testing templates against the largest realistic record, such as a matter with 50 or more related items. For security, check that notifications built from related records do not reveal confidential details to recipients outside the matter. Email design is covered in why basic email automation alone is not enough for enterprise platforms, and access testing in why skipping role-based security testing leads to chaotic go-lives.

How do you test and document complex Liquid?

Complex Liquid is tested by running each expression against records that cover empty lists, single items, many items, missing fields, and every condition branch, in a non-production environment. Each expression is then documented with its purpose and an example output.

Measures worth tracking include the share of rules and templates with test cases, failed evaluations or rendering errors per release, and email render accuracy across test sends. Keep a short library of approved snippets, such as a standard approver list, so builders reuse tested logic. Release practice is covered in release management on configured legal platforms, and documentation in why code without documentation is a ticking time bomb.

Conclusion

Advanced Liquid lets Onit templates and rules handle real records with lists, conditions, and formatted output. Use capture for reusable text, loops with limits for lists, chained filters for clean formatting, and collection filters to keep loops simple. Validate every platform-specific filter for your version, test against empty and large records, and keep a library of approved snippets so complexity stays manageable.

Frequently asked questions

What counts as advanced Liquid?

Advanced Liquid covers capturing text into variables, looping over lists, counters, chaining filters with parameters, and filtering collections before loops. It builds on the same objects, tags, and filters as basic Liquid.

What does the capture tag do in Liquid?

The capture tag collects text, variables, and logic between `capture` and `endcapture` into a new string variable that can be reused later in the template.

How do you stop a Liquid loop early?

You stop a Liquid loop early with the `break` tag, and skip a single item with `continue`. The `limit` parameter caps how many items the loop processes.

Why filter a list before looping in Liquid?

Filtering a list first with filters such as `where`, `sort`, and `uniq` keeps loops simple and reduces processing, since conditions inside a loop run once per item.

Are Onit Liquid filters the same as Shopify Liquid filters?

Onit can add platform-specific filters on top of standard Liquid. Confirm each filter’s name and behavior for your Onit version before using it in production.

How do you test complex Liquid in Onit?

Test complex Liquid against records with empty lists, single items, many items, and missing fields, covering every branch, in a non-production environment before release.

---

*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.*