Data schemas are the building blocks of every Atlas form and record. This guide covers just the schema part of the workflow in detail: creating one, adding fields, and publishing it. If you want the whole form-building journey, see Build your first form in Atlas.
Before you start: decide what belongs together
A data schema should hold fields that always travel together. Good candidates:
- Contact Details — full name, email, phone.
- Service Address — street, city, state, postal code.
- Vehicle — make, model, year, plate.
- Emergency Contact — name, relationship, phone.
If you’re unsure where to draw the lines, read Designing good data schemas first.
1. Create the schema
- Open Data Schemas from the navigation.
- Choose New, then Data Schema.
- Enter a name that describes the group of fields, such as Vehicle.
- Choose Create. The schema joins your list.
- Open it from the list.
The name is how you’ll find the schema later when attaching it to forms, so make it specific.
2. Add fields
Fields are added in the schema’s JSON Schema section.
- Click Edit.
- Click Add a property.
- Set the title — the label people will read on the form.
- Choose a type, such as text, a number or a date.
- Optionally choose a format that adds validation, like Email Address or phone number.
- Mark the field required if every submission must include it.
- Repeat for each field, then Save.
A few examples:
| Title | Type | Format | Required |
|---|---|---|---|
| Make | Text | — | Yes |
| Model | Text | — | Yes |
| Year | Number | — | No |
| Plate | Text | — | No |
3. Publish
After saving, Atlas shows a banner that the schema has unpublished changes. Unpublished changes aren’t visible to forms yet.
Click Publish to make a version available. From now on:
- Forms can attach this schema, and it will show its version number.
- Editing the schema creates a new version instead of changing the old one.
- Forms you’ve already printed and data you’ve already collected keep their original shape.
4. Change it later
Schemas aren’t set in stone. To change one, open it, edit its fields, save, and publish again. That produces a new version. Forms keep the version they were built with until you update them, which lets you roll out a change deliberately rather than all at once. See How schema versioning protects the data you’ve already collected.
Common questions
Can the same schema be used in several forms? Yes — that’s the point. Any data schema can be attached to any form (and, on Enterprise, to any record schema).
Why can’t I attach my schema to a form? Check that it’s published. Only published versions can be attached.
Should I make one big schema with everything? Usually not. Smaller, focused schemas are easier to reuse. A form can attach as many as it needs.
A worked example: an Emergency Contact schema
To see the whole flow on something other than contact details, here’s an Emergency Contact schema a business might use on intake forms:
| Title | Type | Format | Required | Why |
|---|---|---|---|---|
| Name | Text | — | Yes | You can’t call someone you can’t name |
| Relationship | Text | — | No | Helpful context, not essential |
| Phone | Text | Phone number | Yes | The whole point of the schema |
| Text | Email Address | No | A useful backup channel |
Steps: Data Schemas → New → Data Schema → “Emergency Contact” → Create, open it, JSON Schema → Edit → Add a property for each row, Save, then Publish. It’s now available to every form that needs an emergency contact.
A pre-publish checklist
Publishing makes a version official, so a quick review is worthwhile:
- Titles read naturally to someone outside the business.
- Types match how values will be used — numbers for amounts you’ll calculate, text for identifiers like phone numbers and postal codes.
- Formats are set where they help, especially for email and phone.
- Required is set on everything you can’t act without — and nothing else.
- Scope is right: every field belongs to this group of information.
- Name describes the information, not the form it was first built for.
Naming schemas so they’re easy to find
As your library of schemas grows, names become important. Conventions that work:
- Describe the information: Service Address, Billing Address, Vehicle.
- Be specific when two schemas look similar: Service Address and Billing Address rather than two schemas called Address.
- Avoid form names: Intake Contact ties the schema to one form and discourages reuse.
What happens after you publish
Once a version is published:
- It can be attached to any form in its Fields section, where it shows its version number.
- On Enterprise, it can be attached to record schemas inside classifications.
- On Advanced, forms that attach it present it as one step of the public form, with its fields, formats and required markers.
- Further edits create a new version; nothing already attached changes until you update it.
Keeping your schema library healthy
As the number of schemas grows, a little maintenance keeps them useful:
- Check for near-duplicates before creating a new schema; the one you need may already exist under a slightly different name.
- Keep descriptions in the name. A schema called Address invites confusion; Service Address and Billing Address don’t.
- Retire quietly. Stop attaching schemas you no longer use; existing forms and data keep their versions.
- Publish in batches. Group related edits into one new version rather than several in a row.
A tidy library is what makes the next form quick to build.
