Every field in an Atlas data schema comes with three decisions: its type, an optional format, and whether it’s required. They take seconds to make, and they decide whether the data you collect can be trusted.
Types: what kind of value is this?
The type tells Atlas what kind of value a field holds, such as text, a number or a date. Atlas’s documentation also describes boolean, select and reference fields for richer models.
Choose the type that matches how the value will be used, not how it looks:
- Numbers you’ll calculate with — quantities, lot sizes, counts — should be number fields.
- Numbers you won’t calculate with — phone numbers, postal codes, account numbers — are usually better as text, because leading zeros, spaces and dashes matter.
- Dates should be date fields, so they can be sorted and compared.
- Yes/no questions fit a boolean.
Formats: validation for free
A format adds validation to a text field. In the Atlas Basic tutorial:
- Email is text with the Email Address format, so Atlas checks that what’s entered really is an email address.
- Phone uses the phone number format.
Formats are one of the cheapest ways to improve data quality. A malformed email address caught on the form is one you never have to chase later. Because formats live in the schema, they apply everywhere the schema is used — including the public form on the Advanced tier, where respondents see the same fields and formats.
Required: what must every submission include?
Marking a field required means a submission can’t be completed without it. Required fields are marked with an asterisk on the public form.
A good rule: require what you can’t act without. For a service request, you can’t respond without knowing who asked and where the work is, so Full Name, Email, Street and City are required in the tutorial. A phone number is useful but not essential, so it’s optional.
Over-requiring has a cost. Every required field is a reason for someone to abandon a form, or to type something meaningless just to get past it. See Designing intake forms people actually finish.
Titles: what people read
The title is the label on the form. Write it the way your customers talk — “Full Name”, “Street”, “Postal Code” — and keep it short. If a field needs explaining, use the form’s heading and footer for instructions rather than a long title.
A checklist for every field
Before you publish a schema, run each field through five questions:
- Is the title clear to someone outside the business?
- Does the type match how the value will be used?
- Would a format catch common mistakes?
- Can we act without it? If not, make it required.
- Does it belong in this schema, or does it travel with a different group of fields?
Worked examples
Here’s how the five-question checklist plays out on common fields:
| Field | Type | Format | Required? | Reasoning |
|---|---|---|---|---|
| Full Name | Text | — | Yes | You can’t respond without knowing who asked |
| Text | Email Address | Yes | Your main follow-up channel; the format catches typos | |
| Phone | Text | Phone number | No | Useful, but some customers prefer email |
| Postal Code | Text | — | Depends | Text, because leading zeros and letters matter |
| Lot Size | Number | — | No | A number you might compare or total |
| Visit Date | Date | — | Yes | Sortable, comparable, unambiguous |
| Gate Code | Text | — | No | Only some properties have one |
Titles people understand
Field titles are read by people who don’t know your internal vocabulary. A few before-and-after examples:
| Internal title | Customer-friendly title |
|---|---|
| Svc Addr | Where should we do the work? — or simply Street |
| Cust Ph | Phone |
| Req Type | What do you need help with? |
| Prop ID | Leave this to the office (don’t ask customers for internal IDs) |
The last row is a reminder that some fields don’t belong on customer-facing forms at all. Internal identifiers are better captured by staff, or on Enterprise as a topic’s External ID.
Common mistakes
- Numbers for identifiers. Phone numbers, postal codes and account numbers stored as numbers lose leading zeros and formatting.
- Free text for dates. “Next Tuesday”, “3/4” and “March 4th” can’t be sorted or compared.
- Everything required. People abandon long mandatory forms or type placeholder answers.
- No formats on email. The single most common source of failed follow-up.
- Titles that explain too much. Put guidance in section headings or footers and keep titles short.
Frequently asked questions
Can I change a field’s type after publishing? Yes, by editing the schema and publishing a new version. Existing answers keep the version they were collected with.
Do formats apply on printed forms? Formats validate what’s typed into Atlas, such as online submissions. On paper, clear titles and good layout do the same job for the person writing.
Should optional fields be marked? Atlas marks required fields with an asterisk on the public form. If most of your fields are required, consider whether some could be optional instead.
Where are field rules defined — on the form or the schema? On the schema. That’s what makes them apply everywhere the schema is used.
Changing your mind
If you get a decision wrong, fix it and publish again. Publishing creates a new schema version, so answers collected under the old rules keep their original shape. See How schema versioning protects the data you’ve already collected.
