If you learn one Atlas concept, make it the data schema. Nearly everything else in Atlas — forms, record schemas, records, documents — is built by combining data schemas.
The definition
A data schema defines a set of form fields that belong together.
Contact Details is the classic example: a full name, an email address and a phone number. Service Address is another: street, city, state and postal code. You can define as many data schemas as your business needs — contact details, a service address, an insurance policy, a vehicle, an emergency contact.
What’s inside a data schema
Each field in a data schema has:
- A title, which is what people read on the form — “Full Name”, “Email”, “Phone”.
- A type, such as text, a number or a date.
- Rules, such as whether the field is required.
- An optional format, which adds validation. A text field with the Email Address format only accepts a real email address; the phone number format does the same for phone numbers.
In the Atlas interface, you add fields in the schema’s JSON Schema section: choose Edit, then Add a property, and set the title, type, format and whether it’s required. Under the hood, Atlas stores the schema in the widely used JSON Schema standard, which is part of why the same definition can drive forms, records and APIs.
An example
Here’s the Contact Details schema from the Atlas Basic tutorial:
| Field | Type | Format | Required |
|---|---|---|---|
| Full Name | Text | — | Yes |
| Text | Email Address | Yes | |
| Phone | Text | Phone number | No |
Three fields, defined once. From here on, any form that needs to know who a request came from simply attaches Contact Details.
Publishing makes a schema usable
A new or edited data schema isn’t available to forms until you publish it. Atlas shows a banner when a schema has unpublished changes. Publishing makes a version available; after that, editing the schema creates a new version instead of changing the old one.
That’s what keeps your history intact: forms you’ve already printed and data you’ve already collected keep the shape they were built with. See How schema versioning protects the data you’ve already collected.
How data schemas are used
Data schemas are the parts; other things are assembled from them.
- Forms attach data schemas in their Fields section. Each schema you attach becomes its own section of the form, with a layout you control.
- Record schemas are collections of data schemas. A Service Request might combine Contact Details, Service Address and a description of the work. See What is a record schema?
- Public forms on the Advanced tier present each attached data schema as one step of the guided form, with the same fields, formats and required markers.
Because the same definition is used everywhere, what a customer sees and what Atlas will accept can’t drift apart.
Why it matters
Defining fields once solves several problems at the same time:
- Consistency — every form asks the same question the same way.
- Validation — rules like the Email Address format apply everywhere the schema is used.
- Speed — each new form is assembled from schemas you already have.
- Safe change — improvements create new versions instead of rewriting history.
Examples by industry
The same idea applies to almost any business. A few examples of useful data schemas:
| Business | Data schema | Typical fields |
|---|---|---|
| Landscaping | Site Details | Lot size, irrigation, gate |
| Property management | Unit Details | Unit number, bedrooms, parking space |
| Vehicle services | Vehicle | Make, model, year, plate |
| Events | Attendee Preferences | Dietary needs, accessibility requirements |
| Any business | Contact Details | Full name, email, phone |
| Any business | Emergency Contact | Name, relationship, phone |
Notice that the last two rows apply everywhere. Most businesses end up with a small set of universal schemas — contact details, addresses, emergency contacts — plus a few that describe what’s specific to their work.
Data schema vs. form vs. record
People new to Atlas sometimes mix these up. The difference is worth fixing early:
- A data schema is a reusable group of fields. It doesn’t know which form it will appear on.
- A form decides what’s collected and how it’s laid out, by attaching data schemas and arranging them into sections.
- A record schema composes data schemas into one complete record type.
- A record or submission is one filled-in instance — one customer’s answers.
Keeping these separate is what lets the same Contact Details appear on dozens of forms without being rebuilt.
Common mistakes
Making one schema per form. If each form gets its own schema containing every field it needs, nothing is reused, and you’ve recreated the problem schemas are meant to solve. Build schemas around groups of information, not around forms.
Mixing unrelated fields. A schema containing a name, an address and a vehicle make is hard to reuse anywhere that needs only one of those.
Skipping formats. An email field without the Email Address format accepts anything. Formats are cheap and prevent a whole class of follow-up work.
Forgetting to publish. A schema’s changes aren’t available to forms until it’s published. If a form can’t find your schema, check for the unpublished-changes banner.
Frequently asked questions
Can a form use more than one data schema? Yes. The Service Request form in the Basic tutorial attaches two: Contact Details and Service Address. Each becomes its own section.
Can I change a data schema after publishing? Yes. Edit it and publish again to create a new version. Forms and data built on the earlier version keep their original shape.
Do data schemas work on every tier? Yes. They’re part of the free Basic tier and carry through Advanced and Enterprise, where record schemas inside classifications are built from them.
Are data schemas visible to customers? Customers see the fields a schema defines, laid out on the form. They don’t see the schema itself.
Next steps
- How to create and publish a data schema — a step-by-step walkthrough.
- Choosing field types, formats and required fields.
- Designing good data schemas — how to decide which fields belong together.
