Administration

Required Fields

What Required Fields actually controls, entity by entity — and where it stops.

Overview

Required Fields lets an admin change whether a given field on a creation form must be filled in, is left optional, or is removed from the form entirely — per entity, for your whole organization. It covers nine entities across both products: five in Equipt (Purchase Orders, Requisitions, Work Orders, Assets, Vehicles) and four in Landscapt (Clients, Tickets, Estimates, Jobs).

This is narrower than a general field-permissions system — it only governs the specific fields listed on this page, not every field on every record, and (as covered below) two of the nine entities are configurable in the settings UI but not actually read by any form yet.

Where it lives

There are two separate settings screens, one per product, both writing to the same underlying setting:

ScreenCovers
Equipt Settings → Required FieldsPurchase Orders, Requisitions, Work Orders, Assets, Vehicles.
Landscapt Settings → CRM → Required FieldsClients, Tickets, Estimates, Jobs.

Both screens edit the same org-level setting, stored once as your organization's customizations.requiredFields value. There is no per-role version of this setting — every user in your org sees the same required/optional/hidden state on every form, regardless of their role. Changing it on either screen and clicking Save Required Fields applies immediately, org-wide, to every user.

The three states: Required, Optional, Hidden

Every configurable field on this page can be set to one of three states:

  • Required — the form won't let anyone save until the field has a value. The field label gets a red asterisk.
  • Optional — the field is shown, but can be left blank. This is the default state for most fields.
  • Hidden — the field is removed from the form entirely. It doesn't just become uneditable; the input, its label, and its section of the form don't render at all.
Hiding a field only affects the creation form. It doesn't delete existing values already saved on records, and it doesn't remove the field from detail views, reports, or edit screens elsewhere in the product — only from the specific "New …" dialog this page's tables describe.

Equipt: configurable fields

Every field below is read by its entity's creation form. The last column shows what ships as Required out of the box — everything else defaults to Optional, and nothing in Equipt defaults to Hidden.

EntityConfigurable fieldsRequired by default
Purchase OrdersVendor, Project, Notes, Shipping CostVendor
RequisitionsVendor, Title, NotesTitle
Work OrdersPriority, Category, Assigned To, Estimated Hours, Due DatePriority
AssetsLocation, Serial Number, Year, Make / Model— none
VehiclesLicense Plate, Year, Make, Model, MileageYear, Make

A field showing up as required by default doesn't mean it's locked — every field on this page, including Purchase Order Vendor and Work Order Priority, can be switched to Optional or Hidden the same as any other. There is no field on this list that the settings screen refuses to let you loosen.

Landscapt: configurable fields

Landscapt's Required Fields tab shows all four entities, but only two of them are currently wired into a real form:

EntityConfigurable fieldsRequired by default
ClientsPhone, Email, Source— none
TicketsClient, Assigned To, Due Date— none
EstimatesSales Rep, Valid Until— none
JobsCrew, Sales Rep— none

Estimates and Jobs are fully enforced too: the New Estimate dialog reads Sales Rep and Valid Until, and both job-creation paths — New Job and Convert Estimate to Job — read Crew (New Job also reads Sales Rep; Convert Estimate to Job has no Sales Rep field of its own to enforce). Client and Ticket remain enforced the same way, via the New Client dialog, the Client detail edit panel, and the New Ticket dialog.

Always required, no matter what

A handful of fields aren't on the Required Fields screen at all because they're required unconditionally, at the form level — no setting can loosen them:

  • Requisition Title and Work Order Title — both forms block saving on an empty title regardless of any Required Fields setting.
  • Line items on Purchase Orders and Requisitions must reference a Products catalog entry. Every line needs a selected catalog product before the form will save — there is no way to leave a line item's product unselected, hide that requirement, or save a free-text line description in its place.
This second point matches the platform-wide rule that the Products catalog is the single source of truth for anything purchasable: a PO or Requisition line item always points at a real catalog entry, never a free-text description, and Required Fields has no lever over that.

Worked example: requiring Vendor on Requisitions

Requisitions ship with Vendor set to Optional — a requester can submit a requisition before anyone has picked a vendor, since sourcing often happens after the request is approved. Suppose your org wants to skip that step and always capture a vendor up front:

  1. Go to Equipt Settings → Required Fields.
  2. Find the Requisitions card and locate the Vendor row.
  3. Change its dropdown from Optional to Required.
  4. Click Save Required Fields at the bottom of the page.

From that point on, every user who opens the New Requisition dialog sees a red asterisk next to Vendor, and the Save button stays disabled until a vendor is selected — including for requisitions started before the change, if they're still in draft when reopened. Reverting the dropdown back to Optional removes the restriction immediately for everyone, with no effect on requisitions already saved either way.

How enforcement actually works

Required Fields is enforced entirely in the browser, inside the specific creation dialog for each entity. There is no server-side or database check behind it — no API route validates a request against your org's Required Fields setting, and no database constraint rejects a record for missing a field this setting marks Required.

What this means in practice: the setting stops someone from clicking Save in the app UI with a required field blank. It does not, by itself, stop a record from being created with that field empty through any other path — a bulk import, a direct API call, or a future integration that writes to the same tables. Treat Required Fields as UI-level guardrails for people using the app day to day, not as a data guarantee you can rely on everywhere a record might be created.

This is a different mechanism from the required-field checks on the public maintenance-request portal's custom forms, which validate submitted portal forms against each field's own required flag — a separate, form-builder-level setting unrelated to this page.

© 2026 Landscapt. All rights reserved.