If a data schema is a reusable part, a record schema is the thing you build from those parts. It’s the second of the two ideas at the heart of Atlas.
The definition
A record schema is a collection of data schemas. It describes one complete kind of record your business keeps.
A Service Request, for example, might combine:
- Contact Details — who the request came from,
- Service Address — where the work happens, and
- a description of the work.
Here’s what makes this powerful: any data schema can be added to any record schema. Define an address once, then reuse it in every record type that needs one — service requests, inspections, quotes, site surveys.
Record schemas on Basic and Advanced
On the Basic and Advanced tiers, you meet this idea through Forms. When you create a form and attach Contact Details and Service Address in its Fields section, you’re composing a record type from reusable data schemas. Each schema arrives with its version number, so you always know which version a form collects.
The form then decides how that record is laid out on the page — section titles, headings, footers, field order and widths — and, on Advanced, how it’s collected online. See Build your first form in Atlas.
Record schemas on Enterprise
On Enterprise, record schemas live inside a classification and describe what you keep on file for each thing in it. The Enterprise tutorial builds a Property Profile record schema inside a Service Properties data module:
- Inside the module, choose New, then Record Schema.
- Data Classification is fixed to the module you came from. Give the record schema a Name (required) and a Description (also required).
- Creating it only names the record schema. Open it, and in the Schemas section choose Edit to attach data schemas — Service Address and a Site Details schema for the lot, the irrigation and the gate.
- Each attached schema gets its own layout section, and a Preview shows the record as it will look once it’s filled in.
Two rules are worth remembering:
- Only published versions of a data schema can be attached, and each arrives with its version number.
- A record schema always belongs to exactly one classification. The data schemas inside it, by contrast, can be reused by any record schema that needs them.
Records: record schemas, filled in
A record schema is a shape; a data record is that shape filled in for one particular thing. On Enterprise, records attach to topics — one topic for each property, customer or job. Open a topic, choose New, and the record schemas its classification defines appear in the menu, so choosing what to create and choosing what it’s made from are the same decision.
Record schemas vs. sample schemas
Record schemas describe what you keep on file. Measurements taken repeatedly over time — readings, scores, counts — use sample schemas instead. See Samples and aggregations.
Why record schemas matter
Record schemas are where reuse turns into structure. Because every Service Request is built from the same data schemas at known versions, every one of them has the same shape. Reports can compare them. Documents can render them. Applications built on the Atlas API Client can read and write them with the same validation the interface uses.
A worked example: three record schemas, shared parts
Suppose Evergreen Landscaping needs three kinds of record: a service request, a quote request and a site inspection. With reusable data schemas, the three record schemas look like this:
| Record schema | Contact Details | Service Address | Work Description | Site Details |
|---|---|---|---|---|
| Service Request | ✓ | ✓ | ✓ | |
| Quote Request | ✓ | ✓ | ✓ | |
| Site Inspection | ✓ | ✓ |
Four data schemas cover all three record types. Every address in the business has the same shape, and a change to Site Details reaches every record type that uses it once a new version is published.
Designing a record schema
A few questions help decide what a record schema should contain:
- What decision or action does this record support? A service request needs enough to respond; an inspection needs enough to assess a site.
- Which existing data schemas already cover part of it? Reuse those first.
- What’s genuinely unique to this record type? Put that in its own small data schema.
- What changes over time and should be a measurement instead? Model repeated readings as samples rather than fields on the record.
Common mistakes
Recreating fields inside a record schema. Record schemas compose data schemas; if you find yourself wishing you could add a one-off field, create a small data schema for it instead.
Attaching unpublished schemas. Only published versions of a data schema can be attached. Publish first.
One giant record type. A single “Everything” record for every situation is hard to fill in and hard to report on. Several focused record schemas that share data schemas work better.
Ignoring layout. Each attached schema gets its own layout section. A few minutes on titles and order makes records much easier to read.
Frequently asked questions
How many data schemas can a record schema include? Atlas’s features page describes unlimited schema composition per record schema.
Can two classifications share a record schema? A record schema belongs to exactly one classification. What’s shared is the data schemas inside it, which any record schema can reuse.
What happens to records when a data schema gets a new version? Existing records keep the version they were created with. You decide when a record schema should move to the new version.
Where do filled-in records appear? On Basic and Advanced, submissions appear in Data Collection. On Enterprise, data records live inside the topic they describe, in the File System.
