Part 2 — Set Up Your Company · Chapter 10

Custom Fields & Tags

BigWave ships knowing nothing about panel amperage, permit numbers or gate codes. Custom fields teach it your domain, and they run deeper into the product than “extra text boxes” suggests. They appear in grid views, export with everything, merge into documents, drive alerts, and import by the thousand during a rollout.

Where custom fields live

Fields attach to a record type, and where you define them controls their scope:

The two-level pattern from chapter 5 applies. Define globally for fields every project needs, define on the project for fields only one line of work cares about. Work orders can also surface their site’s fields, so a tech opening an inspection job sees the gate code without visiting the site record. Each project chooses whether to show all site fields, only global ones, or none, in Project Options.

Defining a field

Every definition sets a name, a data type (text, number, date, dropdown list, checkbox), whether it’s required, and its group. Groups become sections in the panel list, like Custom Fields: Site Access, which keeps thirty fields navigable. Fields can be restricted per role, so a field can exist without every login seeing it.

Prefer dropdowns to free text anywhere you’ll ever filter or count. Panel Brand as free text yields “Square D”, “SquareD” and “Sq. D” within a month, and no view can group them again.

What to capture, and what to skip

The test for adding a field: who reads this, and where? A field feeding a document template, a grid view someone checks, or an alert earns its place. A field that merely could be useful is a tax on every person who creates a work order, forever.

Commercial (Harbor Grill): the inspection project defines PO Number (required before invoicing, chapter 19), Panel Count, and Inspection Result as a Pass / Fail / Corrections dropdown that feeds the close-out report. Site fields on the Harbor Grill customer carry Gate Code and Manager Cell.

Residential (the Okafors): Residential Service defines almost nothing. One dropdown, Job Source, with Referral, Web and Repeat, because Marcus reads that report monthly. Resist decorating the simple project with the complex project’s fields.

Importing definitions and values

Field definitions import from a spreadsheet, which helps when a big customer hands you their required data dictionary on day one. Field values import too, per work order or site, through the Import / Export Center. That’s how three hundred sites arrive with their gate codes already filled in. Chapter 22.

Tags

Tags are labels, not data. A work order can carry any number of them, and they exist at two scopes: Global Tags under Setup, usable everywhere, and project tags defined per project. Each project’s Tag Report screen counts work orders by tag, and grids filter by them.

Use a tag when the fact is a flag you want to corral jobs by: Warranty, Callback, Night Work. Use a status when it’s a step in the flow. Use a custom field when it has a value, since Permit Number can’t be a tag. The warranty test: if you’d never put it in a form field but you want a report of them, it’s a tag.

Checklist

1. Write each proposed field’s reader and destination next to its name. No reader, no field.
2. Dropdowns over free text for anything filterable.
3. Group fields from the start. Ungrouped fields pile into one long General section.
4. Keep the shared service projects lean. Complexity belongs to the projects that earn it.
5. Review fields yearly and retire the unread ones. Old required fields are how forms rot.