Onit workflow automation is the practice of turning a legal process into a configured Onit app, where each piece of work becomes a record with defined fields, stages, owners, and automated steps. The app replaces the spreadsheet and inbox with one place where every request can be created, routed, tracked, and audited.
Most legal processes that land in Onit start life somewhere messier: a shared spreadsheet for vendor compliance checks, an email alias for contract review requests, a form attached to a ticket. The temptation is to recreate that process screen for screen. The better approach is to model the work first, then configure. This guide walks through that modeling step by step, from choosing the process to measuring whether the app replaced the old way of working.
What is Onit workflow automation?
Onit workflow automation is the configuration of an Onit app that captures one category of legal work, using forms, fields, checklists, workflow stages, and process tracking defined in App Builder. Each request, matter, or contract becomes a record that moves through the configured stages. Many teams still run this by hand, since a 2025 survey of in-house legal teams found 44 percent are still manually creating, assigning, and updating legal work, while a 2024 operations index found 75 percent of legal departments are prioritizing legal technology investments.
Every modeled process has four layers:
- The app. One configured application per category of work, such as contract review or vendor compliance. Some teams call this the business object.
- Records. Individual work items, such as one review request or one vendor check.
- Structure. Forms, fields, checklists, and stages that every record follows.
- Automation. Notifications, approvals, assignments, and status changes that run as records move.
The platform behind this is introduced in what Onit Apptitude is and what it is used for.
Which legal processes suit Onit workflow automation?
Legal processes that suit Onit workflow automation are repeatable, involve more than one person, and currently run on spreadsheets or email. Contract review and approval, matter intake, vendor compliance, and contract management are common starting points.
Signs a process is a good candidate:
- Volume. Twenty or more requests a month, so time saved adds up quickly.
- Handoffs. Work passes between legal, the business, and approvers, and items get lost between them.
- Status questions. People regularly ask where a request stands.
- Audit needs. You need a record of who approved what, and when.
Start with one process that is painful and well understood. A first app that goes live in eight to twelve weeks builds more support than an ambitious program that takes a year. A general method is covered in legal workflow automation, step by step.
How do you map the current process before building?
You map the current process by documenting each step, who performs it, what information they need, how long it takes, and where exceptions occur, using real examples from the last few months. This inventory becomes the blueprint for the app.
Gather three kinds of evidence:
- Real records. Pull 20 to 30 recent examples from the spreadsheet or inbox, including awkward ones.
- Interviews. Talk to requesters, reviewers, and approvers separately, since each sees a different part of the process.
- Exceptions. List the cases that break the normal flow, such as urgent requests or missing information.
Expect to find steps nobody wrote down. These hidden steps are the most common reason a first build misses requirements. Walk the map back through with each group before design starts.
How do you define records, fields, and checklists?
You define records, fields, and checklists by deciding what one unit of work is, which information it must carry at each stage, and which checks must be completed before it moves on. Every field should earn its place by feeding a decision, report, or rule.
Design rules that keep forms usable:
- One record per unit of work. A contract review request is one record, even if it involves several documents.
- Controlled values. Use lists for repeating values such as business unit, contract type, and country, so reporting stays clean.
- Checklists for required steps. Turn “did someone check sanctions?” into a checklist item that must be ticked before approval.
Keep the requester’s form short. Eight to twelve fields at intake is a practical ceiling, with more detail collected later by legal. Intake design is covered in how to design a legal intake process that gets used.
How do you map stages and roles in an Onit app?
You map stages and roles by listing the states a record passes through, such as submitted, in review, awaiting approval, and closed, and naming who can act at each one. Stages and roles together define the workflow.
Practical guidance:
- Few stages. Five to seven stages cover most legal processes. More than ten usually means stages are standing in for tasks.
- Named roles. Requester, legal reviewer, approver, and administrator are typical. Define each role from the business process, so access survives staff changes.
- An owner per stage. Each stage names who must act before the record can move, so nothing waits without an owner.
Write the stage and role map on one page and have each stakeholder group confirm it before configuration starts. Changing stages after go-live affects every open record.
How do you design notifications, approvals, and status changes?
You design notifications, approvals, and status changes by tying each one to a specific event in the workflow, such as submission, assignment, or approval, and stating who is told and what they must do. In Onit, these are configured in Process Builder as actions and groups of actions.
Event design rules:
- Notify for action. Send a notification when someone must do something, and skip it when they need only to know.
- Route approvals by rule. Approval routing should follow written conditions, such as contract value or risk level.
- Automate status moves. When a checklist is complete or an approval is given, move the record to its next stage automatically.
Too many notifications teach people to ignore all of them. Most processes need three to five notifications in total. Approval routing patterns are covered in contract approval workflows that route each agreement by value and risk, and conditional logic in why basic automation fails without advanced conditional logic.
How should related records connect across Onit apps?
Related records should connect across Onit apps through relationships and workflow steps configured in App Builder, so a legal request can create a matter or contract and keep a link back to it. The exact relationship options depend on your configuration.
Decide during design which information carries over when one record creates another, such as requester, business unit, and attachments, and which stays behind. Write these rules down, and test them with three or four real examples that cross apps. Unplanned links produce duplicate data entry, or records that cannot be traced back to the request that started them. Confirm relationship behavior against your Onit version before building.
How do you test a newly modeled Onit app?
You test a newly modeled Onit app by running the real examples gathered during mapping through every stage, with test users in each role, and confirming that fields, checklists, routing, and notifications behave as designed. Exceptions get their own test cases.
Use the 20 to 30 real records from mapping as test scripts, add cases for each exception, and test every role against open and restricted records. Release through a non-production environment. Role testing is covered in why skipping role-based security testing leads to chaotic go-lives.
How do you know Onit workflow automation replaced the old process?
An Onit app has replaced the old process when new work arrives only through it, the spreadsheet or inbox is retired, and cycle times and status questions fall. Measure these within the first three months.
Track the share of the process’s requests created in the app, the share of required fields completed with valid values, automation exceptions such as failed rules or notifications, and average cycle time before and after. Set a date to make the old spreadsheet read-only. While it stays editable, some work will keep flowing there.
Conclusion
Onit workflow automation works best when the process is modeled before anything is configured. Choose a repeatable process with real pain, map it from actual records, define one record per unit of work with controlled fields and checklists, keep stages and notifications few, and test with real examples. Then retire the spreadsheet, and the app becomes the single place your team runs that work.
How Basla can help
Basla provides delivery teams for Onit implementation, covering legal technology consulting, business analysis and process mapping, app and data model design, Process Builder workflow configuration, testing, documentation, and post-go-live support. The team turns spreadsheet and email processes into configured apps, starting from your real records.
Basla built a Legal Service Request implementation with eight Front Doors for language and country variations, and has created and executed more than 1,000 test records for a Contract Lifecycle Management rollout.
Frequently asked questions
What is Onit workflow automation?
Onit workflow automation is configuring an Onit app that captures one category of legal work with forms, fields, checklists, stages, and automated steps. Each work item becomes a record that moves through the configured workflow.
What is a business object in Onit?
A business object is a common name for a configured Onit app that defines the structure and workflow for one category of legal work. Individual work items are managed as records within it.
Which legal processes should be automated in Onit first?
Repeatable processes with high volume, several handoffs, and frequent status questions should come first. Contract review, matter intake, and vendor compliance are common starting points.
How many fields should an Onit intake form have?
Most Onit intake forms work well with eight to twelve fields for the requester. Legal can collect further detail at later stages.
How long does it take to build a first Onit app?
A first Onit app for a well-understood process usually takes eight to twelve weeks, covering mapping, configuration, and testing. Timelines depend on integrations and approval complexity.
Can Onit records link to each other?
Onit records can link through relationships and workflow steps configured in App Builder, such as a legal request creating a matter. The exact options depend on your configuration.
*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.*