Onit App Builder is the configuration layer of the Apptitude platform, providing the workflow and metadata management tools that power every Onit solution, from legal intake and matter management to contract lifecycle management. Builders model business logic visually in Process Builder by placing actions and groups of actions into workflows, without writing code.
That flexibility is the reason Onit fits so many legal processes, and also the reason builds can become hard to maintain. Each rule added without a design pattern makes the next change riskier. This guide looks under the hood: the building blocks of an app, how workflows and actions are modeled, how to design data and security, when to reuse catalog apps, and how you release changes safely. For an introduction to the platform itself, start with what Onit Apptitude is and what it is used for.
What is Onit App Builder in the Apptitude platform?
Onit App Builder is the set of tools within Apptitude used to configure apps: their data, forms, workflows, business rules, and access. Every Onit solution, including ELM and CLM, is built on it. Configuration is where most legal teams have room to grow, since a 2025 survey of in-house legal teams found only 10 percent have significant automation in place. Discipline still matters with low-code tools, because research put the cost of poor software quality in the US at $2.41 trillion in 2022.
What builders work with:
- Process Builder. A visual drag-and-drop interface for building and managing business logic and workflows.
- Prebuilt actions. Ready-made steps that require no code to configure into a workflow.
- Metadata tools. Fields, lists, and record structures that hold the app’s data.
- Configuration for access. Settings that decide who can see and act on each record.
Apptitude is built as a no-code, highly configurable platform. Technical configuration is still involved for complex builds, so plan for skilled builders even when most changes need no code.
What are the building blocks of an Onit Apptitude app?
An Onit Apptitude app is built from records and their fields, forms that present them, workflows that move records through stages, actions and business rules that run at each step, and access settings that control participation. Every requirement maps to one of these blocks.
Mapping requirements to blocks:
- Records and fields. A legal request, a matter, or a contract, with the fields each needs.
- Forms and views. What each user sees at each stage, often conditional on earlier answers.
- Workflow phases. The stages a record moves through, such as intake, review, and approval.
- Actions and rules. Notifications, assignments, calculations, and routing that fire at defined points.
Writing requirements in these terms during analysis makes the build faster and testing clearer. Conditional design is covered in building for scale with conditional UI architecture.
How does Process Builder model a workflow?
Process Builder models a workflow by letting builders drag and drop actions, and groups of actions, onto the points in a process where they should run. The workflow becomes a visible map of what happens, when, and under which conditions.
Design habits that keep workflows readable:
- Group related actions. Bundle the notification, assignment, and field update that belong to one event into one action group.
- Name actions plainly. “Notify approver on submission” is clearer six months later than a default label.
- Keep conditions explicit. Each conditional branch should state its rule, such as contract value above $250,000.
A workflow with 40 or 50 ungrouped actions is hard to change without side effects. Grouping by event keeps most workflows to a dozen or so readable steps. Review grouped workflows with a second builder before release.
How should business rules and actions be configured?
Business rules and actions should be configured from Onit’s prebuilt actions wherever possible, with conditions written to match the documented requirement exactly. Custom logic is reserved for needs the prebuilt actions cannot meet.
Rules that hold up:
- Prebuilt first. Use standard actions for notifications, assignments, and updates, since they behave predictably across upgrades.
- One rule, one place. Avoid repeating the same condition in several workflows, so a change happens once.
- Document every custom element. Record why it exists and what it depends on.
Exact action types and their execution behavior should be confirmed in the App Builder documentation for your version. Why conditional logic matters is covered in why basic automation fails without advanced conditional logic.
How should the Apptitude data model be designed?
The Apptitude data model should be designed around the records your processes act on, the relationships between them, and controlled lists for every repeating value. A clean model makes reporting, routing, and security work without workarounds.
Settle two design points early: how requests, matters, contracts, and invoices link, such as one matter holding many invoices, and which values come from administrator-maintained lists, such as practice area, entity, and country. The exact terms and options for relationships depend on the App Builder configuration, so validate them against platform documentation. Mark fields required only where a later step depends on them, since every required field adds friction for requesters. Changing a relationship after thousands of records exist is slow, so model it before building forms.
How should security be designed in an Onit Apptitude app?
Security in an Onit Apptitude app should combine role-based access, which controls what each group can do, with record-level access, which controls which specific records each user can see. Both need testing against a written security matrix.
Define roles such as requester, legal reviewer, approver, and administrator from the process, and restrict confidential matters or contracts to named groups. The specific participant, group, and private-record model depends on your Onit environment, so validate it during design. Test every role against 20 to 30 records covering open and restricted cases before go-live. Testing practice is covered in why skipping role-based security testing leads to chaotic go-lives.
When should you reuse an Onit catalog app?
You should reuse an Onit catalog app when a proven solution already covers most of your process, and adapt it through configuration. Onit’s App Catalog, launched in 2021, represents more than 5,500 apps and 130 solutions built on Apptitude.
Reuse makes sense when the catalog app covers roughly 70 to 80 percent of the requirement and the gaps are configuration changes. Build from scratch when the process is unusual or the catalog app would need heavy rework. Either way, record what you changed, so upgrades and future builders can see where the app departs from the standard version. Review the catalog before analysis workshops start. Showing stakeholders a working app early often shortens requirement discussions, because people react faster to something they can click through than to a blank specification.
How do you release Onit App Builder changes safely?
Onit App Builder changes are released safely by building in a non-production environment, testing against real scenarios, packaging the change, and deploying it to production on a planned schedule. Every release should be repeatable and traceable.
A dependable release routine:
- Environment discipline. Build and test in sandbox, and never configure directly in production.
- Regression tests. Re-run core scenarios on every release, since a changed action can affect workflows elsewhere.
- Release records. Log each change, its tests, and its approver, so a failed release can be traced and rolled back.
Most teams settle on a monthly or fortnightly release cycle once the app is live, with an emergency path for urgent fixes. Release practice is covered in release management on configured legal platforms and sandbox to production deployment testing.
How do you measure the health of an Onit App Builder build?
The health of an Apptitude build is measured by how much of it runs on standard configuration, how often releases introduce defects, and how many automation exceptions occur. Quarterly review catches growing complexity early.
Useful measures include the share of requirements met through configuration, configuration defects per release, the share of releases deployed without critical defects, automation exceptions such as failed rules or integrations, and cycle-time change after automation. A rising defect rate usually signals that the workflow needs regrouping or the data model needs attention. Keep a short configuration log listing each workflow, its owner, and its last change date, so a new administrator can understand the build within a day or two.
Conclusion
Onit App Builder gives legal teams a powerful way to configure workflows without code, and the architecture behind each app decides whether that power stays manageable. Map requirements to records, forms, workflows, actions, and access. Group actions, prefer prebuilt steps, design the data model early, test security by role, reuse catalog apps where they fit, and release through sandbox every time.
How Basla can help
Basla provides delivery teams for Onit implementation, covering legal technology consulting, business analysis, Apptitude app design, Process Builder workflow and business rule configuration, data model and security design, testing, release management, documentation, and post-go-live support. The team maps your requirements to App Builder building blocks, then tests every workflow and role 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 Onit App Builder?
Onit App Builder is the configuration layer of the Apptitude platform, providing the workflow and metadata management tools behind every Onit solution. It is used to configure data, forms, workflows, rules, and access.
What is Process Builder in Onit?
Process Builder is Apptitude’s visual drag-and-drop interface for building and managing workflows. Builders place actions and groups of actions where they should run in the process.
Is Onit Apptitude no-code?
Apptitude is a no-code, highly configurable platform with prebuilt actions. Complex builds still involve technical configuration, so skilled builders remain important.
How many apps are in the Onit App Catalog?
Onit’s App Catalog represents more than 5,500 apps and 130 solutions built on Apptitude, which can be adapted through configuration.
Should Onit changes be made directly in production?
Onit changes should be built and tested in a non-production environment, then released to production on a planned schedule with regression testing.
How is security set up in an Apptitude app?
Security in an Apptitude app combines role-based access with record-level restrictions. The specific model depends on your Onit environment and should be tested against a written security matrix.
*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.*