Building Custom App Forms With Onit Forms Builder

Onit Forms Builder is Onit’s drag-and-drop tool for configuring forms and managing the fields behind them, used to build the custom app forms that requesters, approvers, and reviewers work in every day. You design the form on a canvas, preview the draft next to the published version, and publish only when it is ready.

Custom app forms decide whether an Onit app gets used. A request form that asks the right questions in the right order gets completed in two minutes. One that shows every field to every user gets abandoned, and the requester goes back to email. Long forms are a measured problem: a large-scale checkout study found the average US checkout shows about 15 form fields, roughly twice the 7 or 8 an ideal one needs.

What is Onit Forms Builder used for?

Onit Forms Builder is used to build and maintain the forms an Onit app shows at launch and on the record itself, combining drag-and-drop layout with a flexible field structure. Three capabilities make it the starting point for any new Apptitude app:

• Build first, publish later. Changes stay in draft until they are tested, so a half-finished form never reaches a requester.
• Reusable formlets. One group of fields, such as counterparty details, can be built once and embedded wherever it is needed.
• Leaner field structure. The data model is designed to cut redundant and duplicate fields, which keeps reporting clean as the app grows from one request type to ten.

Which form types does Onit Forms Builder offer?

Onit Forms Builder offers three form types: root forms, formlets, and embedded grids. Each has a distinct job, and most apps use all three:

• Root forms. The standalone form assigned as an app’s quicklaunch form, its record form, or both. Root forms carry tabs, roles, and visibility rules, and each field can appear on a root form only once.
• Formlets. A set of fields embedded inside a root form. Formlets have no tabs of their own and no separate roles, which makes them ideal for grouping related fields and showing them only when they apply.
• Embedded grids. A specialized form that lets users view and edit selected fields directly on the app’s grid dashboard, by expanding a record with the eye icon beside it.

In a simple build, one root form serves as both the quicklaunch form and the record form. Split them when the requester needs a short launch form and reviewers need a fuller record view.

How do you plan the data model for a custom app form?

You plan the data model for a custom app form by listing every field the process needs, its data type, and who fills it in, before you drag anything onto a canvas. Every record already carries three fields that cannot be deleted and are required on every transaction: `name`, `requester_name`, and `requester_email`. Three planning decisions shape the rest:

• Data types. New fields default to Text. Choose deliberately: Currency for amounts, Attachment for documents, and a Combo field with a fixed value list for anything you will report on, such as department or region.
• System names and labels. The system name is lowercase with underscores and stays fixed. The label is what users see and can be changed freely, so one well-named field can carry a different label on different forms.
• One field, one meaning. Create a single `contract_value` field and reuse it everywhere. Duplicate fields with the same settings split your data across columns and break reports.

A typical legal request app needs 20 to 40 fields once every request type is covered. Getting the list agreed with the business in one or two workshops saves days of rework.

How should root forms and tabs be laid out?

Root forms and tabs should be laid out around the order in which people actually provide information, with the few questions that decide everything else placed first. There is no hard limit on tabs, and the recommended maximum for a root form is five tabs. Three layout rules keep root forms usable:

• Lead with the deciding fields. Request type, region, and value usually decide which other questions apply. Put them at the top of the first tab so the formlets below can respond to them and UI actions can pre-fill and check what follows.
• Assign tabs to roles where it helps. Roles are decoupled from tabs, so assigning a role to a tab is optional. Use it when reviewers need a working tab that requesters never see.
• Show example answers. Placeholder text such as “e.g. ACME Holdings Ltd” helps requesters answer free-text fields the way reviewers expect.

When should you use show-if formlets or cascading list combo formlets?

You should use show-if formlets when a group of fields depends on the values of a few other fields, and cascading list combo (CLC) backed formlets when the group depends on a structured combination of values from a cascading list. Show-if formlets are simpler, so they are the default choice. The three formlet types compare like this:

• Basic formlets. The simplest type, always shown. Use them to group related fields under a formlet title, such as “Counterparty details”.
• Show-if formlets. Rendered on the root form only when their rules are met. They suit cases such as showing data protection questions when the request type is “Vendor agreement” and the vendor will process personal data.
• CLC-backed formlets. Rendered based on combinations of values in a cascading list combo. They are powerful for multi-level structures, such as country, then entity, then business unit, and they add needless complexity when used for simple cases.

The design rules behind those conditions, including what happens to hidden values, are covered in dynamic field conditions.

How do roles and phases shape a custom app form?

Roles and phases shape a custom app form by deciding who can see each part of the form and at which stage of the workflow. New apps come with Requester and Approver roles, and you add others, such as a read-only reviewer for colleagues who need visibility without the ability to edit.

Each role belongs to a single phase, so plan the phase list and the role list together. A simple contract approval app might run Pending Approval then Approved, with Requester and Approver roles and an FYI role set as a read-only reviewer. When an approval should not move the record forward automatically, turn off auto-advance on the phase and let a business rule decide.

What Forms Builder practices keep custom app forms fast and maintainable?

The Forms Builder practices that keep custom app forms fast and maintainable all come down to avoiding repetition. Three habits matter most:

• Do not repeat a field on a form. Syncing repeated fields is unsupported, so the same field placed twice risks data loss. If a formlet already contains the field, remove it from the root form.
• Use formlet titles for headers. Avoid the HTML field type for section headers. A formlet title groups fields and labels the section in one step.
• Use labels to fit each audience. When two departments call the same thing by different names, keep one field and give it a department-appropriate label on each form.

Formlets with many fields take longer to render, so split very large groups into two or three smaller formlets that each appear only when needed.

How do you test a custom app form before publishing?

A custom app form is tested in Forms Builder’s preview, which shows the draft and the currently published version side by side, before anything reaches end users. Set the preview context to the quicklaunch form to test launch, and use an existing record to preview the record form. Three checks catch most defects:

• Path checks. Walk the launch form once for each request type and confirm the right formlets appear and the wrong ones stay hidden.
• Role checks. View the record form as each role, including read-only reviewers, and confirm every tab and field shows only to the people who need it.
• Data checks. Submit test records, then confirm values land in the expected fields on the grid dashboard and in reports.

For a form with 20 to 40 fields and three or four request types, plan one to two days of testing per round. Publish only after the business owner has walked the form themselves. For an existing app moving off the older Wizard, the switch is one-way, so run the same tests against the migrated form before publishing.

Conclusion

Onit Forms Builder makes it practical to build custom app forms that stay short for every user and clean for every report. The results depend on the planning behind the canvas: a data model with one field per meaning, root forms that lead with the deciding questions, show-if formlets for simple conditions and CLC-backed formlets for structured ones, roles and phases designed together, and preview testing for every path and role before you publish.

Frequently asked questions

What is Onit Forms Builder?

Onit Forms Builder is Onit’s drag-and-drop form configuration and field management tool. It lets administrators build forms for an app, preview changes against the published version, and publish when ready.

What is a formlet in Onit?

A formlet is a set of fields embedded inside a root form. Formlets have no tabs or roles of their own, and they can be shown always, shown by rules (show-if formlets), or shown based on cascading list combo values.

How many tabs should a root form have?

A root form has no hard limit on tabs, and Onit recommends keeping it to five or fewer. More tabs make long forms harder to complete and slower to review.

Should I use show-if formlets or CLC-backed formlets?

Use show-if formlets when a group of fields depends on a few field values, since they are simpler to build and maintain. Use CLC-backed formlets for structured combinations, such as country, entity, and business unit.

Which fields are required on every Onit record?

Every Onit record requires `name`, `requester_name`, and `requester_email`. These default fields cannot be deleted, so plan your launch form so they are captured automatically or asked once.

Can you go back to the Wizard after migrating to Forms Builder?

You cannot go back to the Wizard after enabling Forms Builder on an app, because the Wizard is no longer available once the migration is confirmed. Review and test the migrated form carefully before publishing.

---

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