Every business eventually changes its forms. A field gets added, a question gets reworded, an optional answer becomes required. The question is what happens to everything you collected before the change.
Atlas’s answer is versioning: a published schema is never edited in place. Changing it produces a new version, and everything built on the old version keeps working exactly as it did.
How versions are created
Versions come from publishing.
- You create or edit a data schema. While you work, Atlas shows a banner that the schema has unpublished changes.
- You choose Publish. That makes a version available to your forms.
- From then on, editing the schema creates a new version instead of changing the published one.
Drafting is free and private to the schema; publishing is the moment a shape becomes official.
Where you see version numbers
Atlas makes versions visible wherever a schema is used:
- When you attach a data schema to a form, it arrives with its version number, so you always know which version a form collects.
- On Enterprise, when you attach a data schema to a record schema, only published versions can be attached, and each shows its version number.
- Document templates bind to a record schema version, so a generated document reflects the model it was designed for.
What versioning protects
Printed forms. A form you printed last month was built from a specific version. It stays valid; the paper in the truck still matches what Atlas expects from it.
Collected data. Submissions and records keep their original shape. Adding a field later doesn’t make old entries look incomplete or reinterpret their answers.
Documents. Because templates are tied to a schema version, a generated document always reflects your model — never a stale copy-paste.
Integrations. Applications that read and write records through the Atlas API Client can rely on the shape of the schema version they were written against.
A worked example
Evergreen Landscaping, the example business in the Atlas tutorials, uses a Service Address schema with street, city, state and postal code. The team decides to add a gate code.
- They edit Service Address, add a Gate Code field, and publish. That’s a new version.
- The Service Request form still shows the version it was built with until someone updates it to the new version.
- Service requests already submitted keep the shape they were collected with.
- The next form they build can attach the new version from the start.
Nothing is silently rewritten, and nothing breaks.
Why “edit in place” is a trap
Tools that let you edit a live form in place feel convenient, but they create a subtle problem: the same stored answer can mean different things depending on when it was collected, with nothing to tell you which. That’s how schema drift starts. Versioning trades a little ceremony — the Publish step — for a history you can trust.
A timeline of one schema
It can help to see versions as a timeline. Here’s a plausible history for Evergreen Landscaping’s Service Address schema:
| Version | Change | What it means for existing data |
|---|---|---|
| 1 | Street, City, State, Postal Code | The first forms and submissions use this shape |
| 2 | Gate Code added | Earlier submissions stay on version 1 and simply don’t have a gate code |
| 3 | State made required | Earlier submissions aren’t suddenly “incomplete”; they were collected under earlier rules |
At every point, anyone reading a submission can tell which version of the questions it answered, because the form shows the version it collects.
When to publish a new version
Publish a new version when the meaning or rules of the information change:
- adding or removing a field,
- changing whether a field is required,
- changing a field’s type or format,
- clarifying a field’s title in a way that changes what people will answer.
Group related changes and publish them together, rather than publishing several versions in quick succession.
Rolling a new version out to forms
A new version doesn’t automatically change your forms. That’s deliberate: it lets you decide which forms should adopt the change and when. A simple rollout:
- Publish the new version of the data schema.
- List the forms (and, on Enterprise, record schemas) that attach the schema.
- Update each one to the new version when it makes sense — often immediately for online forms, at the next print run for paper ones.
- Tell the team what changed and why.
Common questions
Can I undo a publish? Versions are how Atlas preserves history, so the right way to reverse a change is to publish another version that restores the earlier shape.
Do I need a new version to fix a typo in a title? A title change is still a change to the published schema, so it produces a new version. That’s a small cost for a history you can trust.
Does versioning apply to classifications too? Versioning described here applies to schemas. Classifications are containers whose record schemas and data schemas carry their own versions.
What happens to documents generated earlier? Document templates bind to a record schema version, so documents reflect the model they were designed for.
Good practices
- Publish deliberately. Treat publishing as a release. Make related edits together, then publish once.
- Name fields for meaning. A field called Service Address won’t need to change meaning later; one called Address might.
- Update forms intentionally. When a new version is published, decide which forms should move to it rather than assuming all of them should.
For the bigger picture on keeping data consistent, see Data quality starts at the point of entry.
