Onit UI actions are configured actions that update or validate field values in real time on an app’s launch page, firing whenever a linked field changes as the user fills in the form. They let a form total amounts, pre-fill a department, or reject a malformed charge code before the request is ever submitted.
That real-time behavior is what separates a launch form that helps people from one that simply records what they type. A requester who sees an error the moment a code does not match their department submits cleaner data. Intake effort is a known pain point, and a 2025 survey of more than 110 in-house legal professionals found 54 percent of legal teams rank streamlining intake and matter management as a priority.
What are Onit UI actions?
Onit UI actions are launch page actions, configured in the Advanced Designer, that recalculate or check field values as the user works through a form built in Onit Forms Builder. The most common type is Update Fields, which bundles three components:
- Field updates. Each update names a target field and a Liquid expression that produces its new value, such as a sum of three currency fields.
- Field validations. Each validation names a field, a message type, and a Liquid condition that decides whether the entry is acceptable.
- Shared Liquid. A block of reusable calculations that both the field updates and the validations can draw on.
A UI action does nothing until it is attached to one or more trigger fields. Once attached, it runs every time any of those fields changes. That trigger-and-response model is the core of UI action architecture, and it complements the show and hide logic of dynamic field conditions.
How do UI actions differ from field calculations and business rules?
UI actions differ from field calculations and business rules in timing: UI actions run while the user is still filling in the launch page, while field calculations and business rules run when a transaction is created or updated. Choosing the right one comes down to when the value needs to exist:
- UI actions. Use them when the user should see the result before submitting, such as a running total, a pre-filled department, or an immediate validation message.
- Field calculations and business rules. Use calculations for values computed on creation or update, and business rules for actions such as routing, notifications, and related records that belong after submission.
- Both together. Many apps show a running total with a UI action and recompute it with a field calculation on save, so the stored value never depends on the browser.
How do you build an Update Fields UI action in Onit?
You build an Update Fields UI action by creating the fields, adding the action under UI Actions in the Advanced Designer, writing the Liquid for each field update, and then attaching the action to every field that should trigger it. A simple “line item total” example shows the four steps:
- Create the fields. Three currency fields for the line items and a fourth currency field for the total, set to read only so users cannot overwrite it.
- Add the UI action. In the Advanced Designer, choose Update Fields from the Add dropdown under UI Actions and give it a descriptive name such as “Get Total”.
- Write the field update. Add a field update targeting the total field, with Liquid that adds the three item values together.
- Attach the triggers. Open each item field’s properties, select the UI action from its UI Action dropdown, and update the app.
The trigger list is where most mistakes happen. If one of the three item fields is left unattached, the total stays stale whenever that field changes, and nobody notices until the numbers fail to reconcile.
How does Shared Liquid keep UI actions efficient?
Shared Liquid keeps UI actions efficient by running a calculation once with an `assign` tag and letting every field update and validation in the action reuse the result. Without it, the same lookup or calculation would be repeated in every expression that needs it.
A common pattern loads the full details of a related record once in Shared Liquid, using a list lookup against a transaction list provider, then reads individual values with dot notation in each field update. The action makes one lookup and fills several fields, and the logic sits in one place when it needs to change. Name shared variables clearly, such as `selected_vendor` or `department_code`, so the next administrator can follow the chain without testing every line.
How do UI actions pre-populate a launch form?
UI actions pre-populate a launch form through the app setting “UI Actions to run on launch”, which fires the selected action automatically when a user opens the launch screen. A typical use fills the department field by looking up the current user’s department, so the requester never has to choose it.
A run-on-launch action must still be assigned to a field to work properly, so many builds attach it to a dedicated hidden field kept for that purpose. Pre-filled fields are among the simplest ways to shorten a form, and enterprise legal intake forms work best when every question earns its place.
How do UI validations work in Onit?
UI validations in Onit are Liquid conditions attached to a field inside an Update Fields UI action, checked on the launch screen as the user enters data. Because they use Liquid, they can make decisions and perform list lookups, which regex validators cannot. Each validation carries one of two message types. Error prevents the record from being created until the entry is fixed, which suits values that would break routing, billing, or reporting. Info shows a message without blocking submission, which suits guidance such as flagging an unusually high amount.
A good example checks a charge code in the format XXX-YYYYYY, where the first three characters must match the requester’s department. The validation slices the first three characters, looks up the department’s ID in a list, and returns an error when they differ. The requester learns about the mistake while still on the form, which saves a round trip with finance later.
Use Error sparingly, since every blocking validation is a point where a requester can get stuck.
What limits shape UI action architecture in Onit?
The limits that shape UI action architecture in Onit are few and firm, and designing around them from the start avoids rework. Three matter most:
- No self-updates. A UI action cannot update the same field it is applied to, so the trigger field and the target field must always be different.
- Run on launch needs a field. An action selected to run on launch must also be assigned to a field, or it will not work properly.
- Launch caching conflicts. The “Cache Metadata On Launch” setting can return stale data to run-on-launch actions, so leave it off for apps that rely on them.
Beyond these, keep each UI action focused on one job. An action that totals amounts, pre-fills a department, and validates a code is hard to test and harder to change. Three small actions, each named for its purpose, are easier to maintain than one large one.
Keep a short register as well: one line per UI action listing its name, trigger fields, target fields, validations, and business reason, so a change to one trigger field shows every action it touches.
How do you test Onit UI actions before go-live?
Onit UI actions are tested by changing every trigger field on the launch page and confirming each target field and validation responds as designed, under each role that uses the form. Three test cases cover most of the risk:
- Trigger coverage. Change each trigger field one at a time and confirm the target updates every time. A missed attachment shows up immediately.
- Validation boundaries. Enter a valid value, an invalid value, and an empty value for each validated field, and confirm Error blocks submission while Info does not.
- Launch behavior. Open the launch screen fresh as two or three different users and confirm run-on-launch values reflect each user’s own data.
For a form with five to ten UI actions, plan a day of focused testing, then repeat the launch checks after deployment.
Conclusion
Onit UI actions turn a launch form from a passive set of boxes into a form that calculates, pre-fills, and checks as people type. A reliable design keeps each action focused on one job, attaches it to every field that should trigger it, uses Shared Liquid for repeated lookups, separates the trigger field from the target field, and treats run-on-launch settings with care. Test every trigger, validation, and launch path, and your forms will collect cleaner data from the first request onward.
How Basla can help
Basla provides delivery teams for Onit implementation, covering legal technology consulting, business analysis, launch form and UI action design, Liquid configuration, validation design, testing, documentation, and post-go-live support. That includes designing which fields calculate, pre-fill, and validate, building focused UI actions with shared lookups, and proving every trigger and role before launch.
The team has built eight Legal Service Request “Front Doors” to handle language and country variations for a single enterprise legal department, and has delivered matter management and eBilling across more than 10 global jurisdictions. That delivery discipline takes the weight off your administrators while form logic is designed, built, and tested.
Frequently asked questions
What are Onit UI actions?
Onit UI actions are configured actions that update or validate field values in real time on an app’s launch page. They fire when a linked trigger field changes, so totals, defaults, and validation messages appear before the user submits.
What is the difference between a UI action and a field calculation?
A UI action updates values while the user is filling in the launch page. A field calculation computes a value when a transaction is created or updated. Many apps use both, showing a live value with a UI action and storing a recalculated value on save.
Can a UI action update the field it is attached to?
A UI action cannot update the same field it is applied to. Attach the action to the fields that should trigger it, and target a different field with the update.
How do you run a UI action when the launch page opens?
Select the action under “UI Actions to run on launch” in the app’s settings, and make sure it is also assigned to a field, often a hidden one. Avoid combining it with the Cache Metadata On Launch setting.
What is the difference between Error and Info validations?
An Error validation prevents the record from being created until the entry is corrected. An Info validation shows a message without blocking submission, which suits guidance and warnings.
How do you clear a multiselect field with a UI action?
Clear a multiselect field by setting its value to an empty JSON array, written as []. An empty string does not clear a multiselect field in a UI action.
*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.*