What it does

Forms are the record-level UI in a model-driven app. There are four types — main, quick create, quick view and card — and a table can have several of each, with main forms assignable to security roles so different groups see a layout built for their job.

Key facts

• Main is the full record UI with tabs, sections and the widest range of controls. Quick create is a cut-down form for creating records fast. Quick view shows read-only data from a related record inside another form, driven by a lookup. Card is the compact format used in views and on small screens.
• Only main forms can be assigned to security roles. Quick create, quick view and card forms can't.
• Because every user must get a form, at least one main form has to be designated a fallback — the form shown to users whose roles have no form explicitly assigned. Fallback applies to main forms only.
• Form settings, reached from the Forms area or the form designer command bar, cover four things: security roles, form order, fallback forms and the form access checker.
• Form order decides which of the available forms is the default. It's separate from security roles — order picks the default, roles decide who sees what.
• Whichever form a user selects from the form selector becomes their default until they pick another one.
• Main forms can be set active or inactive. Making one inactive is another way to stop users reaching it.
• Main forms are designed once per table and rendered responsively across web, tablet and phone — there's no separate phone form editor. The tablet layout is auto-generated from the main form.
• Business process flow steps write into the form's columns, so business rules and form scripts fire on those changes immediately. Columns set by a BPF step that aren't on the form are still added to the form's object model for scripting.
• Hiding a column on the form also hides it in the business process flow control.
• Form scripting uses the Client API formContext, obtained from the execution context's getFormContext. The old Xrm.Page object is deprecated.
• Form OnLoad and OnSave handlers can return a Promise and the platform will wait for it, up to a timeout. That async support is enabled through app settings.

When to use / skip

Multiple role-based main forms are worth it when two groups genuinely do different jobs on the same record — a manager who reads and a coordinator who types. They're not worth it as a way of hiding three fields from one team; use field-level security or a business rule for that, because every extra form is a form you now maintain forever. Quick create earns its place wherever people create records in bulk or mid-flow from a lookup. Quick view is underused and should be your first answer to "can we show the account's phone number on the case".

Configuration decisions

• How many main forms per table, and whether the split is by role or by task. Fewer is almost always better.
• Which form is the fallback and what strategy it follows — a deliberately minimal contingency form visible only to administrators and unassigned users, or a generic form that works for everybody.
• Form order, ranked most exclusive to least, with the fallback at the bottom.
• Which controls live on the default tab and which go to secondary tabs, because that's a performance decision as much as a layout one.
• Whether logic sits in business rules (declarative, portable, limited) or JavaScript (unlimited, and now your code to maintain).
• Whether quick create is enabled per table, and whether the quick create form is genuinely quick.

Gotchas

• Role-based forms are a UI convenience, not a security boundary. A user who can read the record can read the columns regardless of which form they're shown. If the requirement is confidentiality, that's field-level security.
• Forget the fallback and users with no matching role get a form nobody designed for them.
• The form selector lets users pick any main form they have access to and it sticks. A user who once chose the wrong form will stay on it and report the app as broken.
• Every main form multiplies your change effort. Add a column and you're editing it on four forms, and someone will miss one.
• Xrm.Page is deprecated but still works in a lot of inherited code. Inherited scripts are the most common blocker on an upgrade.
• Async in OnChange isn't supported the way it is in OnLoad and OnSave. Code that awaits and then touches the form context can find the user has already navigated away.

Consultant notes

• Resist the client's instinct to create a form per department. Ask what's actually different on each, and most of the time the answer is two fields and a tab order.
• The form access checker is the fastest way to answer "why is this user seeing that form", and almost nobody knows it exists. Use it in support handover training.
• Layout is a performance conversation, not just a design one. Put the subgrids and timelines on secondary tabs and say why, so nobody moves them back.
• If you're inheriting an estate, audit for Xrm.Page usage early and price the remediation. It's a known deprecation and it will surface at the worst time.
• Design the form once and let responsiveness do its job. Building for a specific screen width in a model-driven app is effort with no payoff.

---

Worth another look if role assignment extends beyond main forms, or when the deprecated client APIs are finally switched off.