Custom Fields Builder

Design custom fields with definitions, field types, validation, visibility, bulk values, and controlled module rollout.

3 lessons 45 min 5-question assessment 70% to pass

What you’ll learn

Define custom fields around real operational decisions

Choose field types that produce clean reporting data

Use validation and visibility to reduce bad entry

Roll out bulk values and modules without confusing users

Lesson 1 of 3 Reading 13 min

Definitions before fields

A custom field should exist because the business needs structured information that the standard module does not already capture. The definition should name the module, label, purpose, owner, and reporting use.

Adding fields casually creates clutter and weak data. Before building a field, ask who will fill it, who will rely on it, what choices are allowed, and whether it should be required.

In practice, a clinic may add an expiry-risk classification to items, while a construction company may add site code to assets. The field is justified by the decision it supports.

Field definition guide

Decision need	Good field type	Why
Controlled risk level	Select list	Keeps reports consistent
Warranty expiry	Date	Allows date filtering and alerts
Compliance evidence	File or attachment reference	Connects proof to record
Free-form note	Text	Use only when structured choices do not fit

Key takeaways

Custom fields should support a real decision or control.
Definition includes module, label, purpose, owner, and reporting use.
Fields without owners become clutter.
Do not duplicate information already captured by standard fields.

Lesson 2 of 3 Workshop 17 min

Types, validation, and visibility

Field type controls data quality. A date field, number field, select list, checkbox, text field, or file reference produces different reporting behavior and different user effort.

Validation and visibility keep entry clean. Required rules, allowed values, module scope, role visibility, and conditional display should guide the user instead of leaving every field open everywhere.

In practice, a warranty expiry date should be a date field, not free text. A controlled risk level should be a select list, not a paragraph field that produces five spellings of the same value.

Key takeaways

The field type shapes reporting quality.
Select lists are better for controlled categories.
Date and number fields should not be stored as free text.
Visibility rules keep fields relevant to the right users and modules.

Lesson 3 of 3 Practice 15 min

Bulk values and rollout

Bulk values are useful when existing records need the new field filled consistently. They should be planned carefully because a bulk update can spread a wrong value across many items, customers, assets, or documents.

Rollout should include a field owner, short instruction, sample records, reporting check, and a review date. Users should know why the field appears and what a good value looks like.

In practice, rolling out a new item compliance field may start with one category, a test report, and a warehouse review before making it required across every item. Controlled rollout protects adoption.

Key takeaways

Bulk values should be checked before applying widely.
Rollout needs owner, instruction, sample records, and review date.
Test the report outcome before forcing required entry.
Start with the module or category where the field matters most.

| AWRA OpsHub

Custom Fields Builder

What you’ll learn

Course content

Definitions before fields

Types, validation, and visibility

Bulk values and rollout

Finished the material?

More in this path

Workflow Builder Basics

Approval Workflows

Security & Data Protection

Need a quick answer while you read?

AwraIQ