A data schema is easy to create. Designing a set of schemas that stays useful as your business grows takes a little more thought. The goal is simple: schemas that get reused rather than copied.
Rule 1: Group fields that always travel together
The best test for whether fields belong in one schema is whether they’re ever needed apart. A street without a city is useless, so they belong together in Service Address. A full name and an email address are almost always asked for together, so they belong in Contact Details.
Fields that are sometimes needed without each other belong in separate schemas.
Rule 2: Prefer small, focused schemas
Because a form or record schema can attach as many data schemas as it needs, there’s no penalty for small schemas — and a real penalty for large ones. A 30-field “Customer” schema can’t be reused anywhere that needs only a contact and an address, so it gets copied and trimmed, and the copies drift apart.
A reasonable size is the number of fields that answer one question: who is this?, where is it?, what vehicle?
Rule 3: Name schemas for what they describe
Name a schema after the information it holds, not the form it was first built for.
| Instead of | Use |
|---|---|
| Request Form Address | Service Address |
| Intake Contact | Contact Details |
| Survey Lot Info | Site Details |
A well-named schema is one someone else will find and reuse.
Rule 4: Separate “who”, “where” and “what”
Most records combine three kinds of information:
- Who — the person or organization involved: Contact Details, Emergency Contact.
- Where — a location: Service Address, Billing Address.
- What — the details specific to this kind of record: Site Details, Vehicle, Work Description.
Keeping these separate makes the “who” and “where” schemas reusable across almost every record type, while the “what” schemas capture what’s unique.
Rule 5: Distinguish similar-looking information
A service address and a billing address may have identical fields, but they mean different things. If both appear on the same record, make them clearly distinct so nobody confuses them later. Meaning matters more than shape.
Rule 6: Decide rules at the schema level
Types, formats and required flags live in the schema, so they apply everywhere it’s used. Decide them once, carefully: see Choosing field types, formats and required fields.
Rule 7: Keep measurements out of record schemas
If you capture the same measurement repeatedly over time — a reading, a count, a score — model it as a sample, not as fields on a record. See Samples and aggregations.
A worked example
Evergreen Landscaping needs to capture service requests and property profiles. A good schema set:
- Contact Details — Full Name, Email, Phone
- Service Address — Street, City, State, Postal Code
- Site Details — lot, irrigation, gate
The Service Request form attaches Contact Details and Service Address. On Enterprise, the Property Profile record schema attaches Service Address and Site Details. Three schemas, no duplicated fields, and every address in the business has the same shape.
A review process for your schema set
Once a quarter, or before a big new form, review your schemas with a few questions:
- Are there near-duplicates? Merge them into one well-named schema.
- Is any schema too large to reuse? Split it into focused groups.
- Are required rules consistent with how the information is used?
- Do names still describe the information rather than a form or a team?
- Are there free-form fields people fill in inconsistently? Consider a type, a format or a fixed set of options.
Record decisions in a short note so the reasoning survives when team members change.
Anti-patterns to avoid
The god schema. One schema with every field the business has ever needed. It’s attached everywhere, most of its fields are irrelevant on most forms, and changing it risks everything.
The form mirror. One schema per form, containing exactly that form’s fields. Nothing is reused, and the same questions drift apart across forms.
The ambiguous twin. Two schemas with similar names and slightly different fields — Address and Addresses — that nobody can tell apart.
The kitchen-sink notes field. A long free-text field that collects information which really has structure, such as a date, a quantity or a choice.
Designing for the Enterprise tier
If you expect to move to Enterprise, a little foresight helps. On Enterprise, record schemas live inside classifications and are built from your data schemas. Schemas designed around “who”, “where” and “what” slot naturally into record schemas like Customer Profile or Property Profile. Schemas designed around specific forms have to be reworked first.
Frequently asked questions
How many fields should a schema have? As many as answer one question — who, where, or what. For most schemas that’s somewhere between two and ten.
Should an address include a country? If you ever serve more than one country, yes. Adding it later means a new version; adding it at the start avoids the question.
Can a schema be retired? Stop attaching it to new forms. Existing forms and data keep their versions, so history stays intact.
When to revisit
Revisit your schema set when you notice a copy — two schemas with nearly the same fields. That’s the signal to merge them into one well-named schema and publish it, so future forms reuse a single definition. For the bigger modeling picture, read Entities, attributes and relationships: data modeling in plain language.
