Atlas Enterprise lets you describe your business in your own terms. That freedom raises an obvious question: where do you start? This article walks through a method that works for most businesses, using Evergreen Landscaping — the example business from the Atlas tutorials — as the running example.
Step 1: List the things you keep track of
Start with nouns. Ask the team, “What do we keep track of?” and write down every answer without judging it.
For Evergreen Landscaping: customers, properties, site surveys, crews, equipment, service visits, quotes, invoices.
Then cross out tasks and states. Billing is a task; invoices are things. Overdue is a state; it belongs on a record, not as its own classification.
Step 2: Decide what stands alone
For each thing, ask whether it makes sense without a parent and whether each instance belongs to exactly one of something else. That decides whether it’s a data module or a resource.
| Thing | Position |
|---|---|
| Customers | Data module |
| Properties | Data module |
| Site surveys | Resource of Properties — each belongs to one property |
| Crews | Data module |
| Equipment | Data module |
| Service visits | Resource of Properties |
Resources go one level deep, so prefer data modules for anything with an independent life. See Data modules and resources.
Step 3: Find the reusable data schemas
Look across everything you’ll keep on file and pick out the groups of fields that repeat. For Evergreen: Contact Details, Service Address, Site Details. These become data schemas — probably ones you already built on the Basic tier. See Designing good data schemas.
Step 4: Define a record schema for each classification
For each classification, decide what you keep on file for one of its topics, and compose it from data schemas:
- Properties → Property Profile: Service Address + Site Details.
- Customers → Customer Profile: Contact Details + a billing address schema.
- Service visits → Visit Report: a work summary schema + any measurements as samples.
A record schema belongs to exactly one classification; the data schemas inside it are reused everywhere.
Step 5: Set rules with instance counts and automation
Turn business rules into structure:
- Every property has exactly one site survey → Min and Max Instance Count of 1 on the Site Surveys resource, with Generate Sub-topics Automatically so one is created for every new property.
- No natural limit on customers → leave counts off.
Step 6: Decide who owns and who can see what
Sketch your security policies:
- Which roles need to discover, read, write or archive each classification?
- Which user group has Manage access and answers for it?
Write a few shared policies — Field Crew Access, Office Staff Access — rather than one per classification. See Security policies explained.
Step 7: Build one slice, then grow
Don’t build the whole model at once. Create one data module, its record schema and a handful of topics, and use it for real work for a week. You’ll learn more from that week than from another hour at the whiteboard. Then add the next classification.
Signs your model is working
- New team members can find things in the File System without asking.
- Every topic has an owning group, and Unassigned Topics stays empty.
- Reports compare like with like, because every record of a kind has the same shape.
- When the business adds something new, you add a classification — you don’t start over.
A worked model for Evergreen Landscaping
Putting the seven steps together, here’s a complete first model:
Data schemas (reusable): Contact Details; Service Address; Site Details; Work Description.
Classifications:
| Classification | Position | Record schemas | Notes |
|---|---|---|---|
| Customers | Data module | Customer Profile (Contact Details + billing address) | Owned by Office Staff |
| Properties | Data module | Property Profile (Service Address + Site Details) | Owned by the regional crew group |
| Site Surveys | Resource of Properties | Survey Report (Site Details + Work Description) | Min/Max 1 per property, generated automatically |
| Crews | Data module | Crew Profile (Contact Details) | Owned by Operations |
Security policies: Office Staff Access (Read/Write on Customers and Properties), Field Crew Access (Discover/Read on Properties), each granting Manage to the responsible user group.
That’s a complete, workable model with four data schemas, four classifications and two policies — small enough to build in a day, and rich enough to run the business on.
Sequencing the build
Build in an order that lets you use the system as you go:
- Data schemas first, since everything else composes them.
- The classification that most work revolves around — usually locations or customers.
- Its record schema, then a handful of real topics.
- Security policies and ownership before you invite the wider team.
- Resources and automation once the parent classification is in use.
- The next classification, repeating the pattern.
Warning signs your model needs another look
- People keep a spreadsheet beside Atlas for something the model doesn’t hold.
- The same information is entered in two classifications.
- A classification’s name is a verb.
- Topics routinely sit in Unassigned Topics.
- You need three levels of nesting to express a relationship.
Each of these has a straightforward fix: add the missing classification, consolidate the duplicated information, rename, assign ownership, or flatten the hierarchy and connect through records instead.
Keeping the model documented
Your model lives in Atlas, but a one-page summary helps people understand it: the list of classifications, what each holds, who owns it, and which data schemas are shared. Classification descriptions — required, up to 256 characters — do much of this work inside the product.
