Every classification in Atlas takes one of two positions. Choosing the right one for each kind of thing you track is the most important modeling decision on the Enterprise tier.
The two positions
A data module sits at the top, and its topics stand on their own. A property, a customer, a piece of equipment — each exists independently of anything else.
A resource sits inside a data module, and each of its topics belongs to one topic of the module. A site survey belongs to one particular property. An inspection belongs to one particular vehicle.
Resources go one level deep, so decide early which of your things stand alone.
A simple test
Ask two questions about each kind of thing you track:
- Does it make sense without a parent? If you’d still keep it after the thing it relates to was gone, it probably stands alone: a data module.
- Does each one belong to exactly one of something else? If every instance is about one particular parent — this property’s survey, this vehicle’s inspection — it’s a resource.
| Thing | Stands alone? | Position |
|---|---|---|
| Customers | Yes | Data module |
| Properties | Yes | Data module |
| Site surveys | No — each belongs to one property | Resource of Properties |
| Equipment | Yes | Data module |
| Maintenance visits | No — each belongs to one piece of equipment | Resource of Equipment |
When something relates to several things
Some things relate to more than one parent — a job might involve a customer, a property and a crew. Because resources belong to exactly one parent topic and go one level deep, the usual answer is to make the most independent things data modules and connect the rest through records. Atlas’s documentation describes reference fields that link to other topics and records, which is how connections across modules are expressed without forcing everything into one hierarchy.
Instance counts on resources
Resources make instance counts especially useful, because for a resource the count applies inside each parent topic:
- Min. Instance Count 1 means every property must keep at least one site survey; Atlas refuses to archive the last one.
- Max. Instance Count 1 means a property can have at most one site survey.
Automatic sub-topics
Resources also offer Automation, which answers: when someone creates a topic in the parent, should Atlas create this classification’s topics for them?
- Generate Sub-topics Automatically creates them, using the Min. Instance Count as the number. A resource that requires one site survey gets one automatically for every new property.
- Override Sub-topic Count lets you choose a different number, even zero.
Automation turns a rule (“every property has a survey”) into structure, so nobody has to remember to create the survey.
Common mistakes
- Making a task a classification. Inspecting is a task; Inspections is a thing. Name the things.
- Nesting too early. If you’re not sure something always belongs to one parent, start it as a data module.
- Planning more than one level of nesting. Resources go one level deep; design with that in mind.
A decision flowchart in words
For each kind of thing you track, work through these questions in order:
- Would it exist if nothing else did? Yes → data module.
- Does each one belong to exactly one parent thing? Yes → resource of that parent.
- Does each one relate to several things? Make the most independent thing a data module, and connect the rest through records that reference it.
- Is it really a step in a process rather than a thing? Then it belongs in a pipeline, not a classification.
Worked examples across industries
| Business | Data modules | Resources |
|---|---|---|
| Landscaping | Customers, Properties, Crews | Site surveys (of Properties), Service visits (of Properties) |
| Property management | Buildings, Tenants | Units (of Buildings), Inspections (of Units)* |
| Equipment rental | Customers, Equipment | Maintenance records (of Equipment) |
| Professional services | Clients, Engagements | Deliverables (of Engagements) |
* Note the depth limit: if units are resources of buildings, inspections can’t also be resources of units, because resources go one level deep. In that case, make Units a data module in its own right and relate it to Buildings through records.
Migrating a decision you got wrong
If something was created as a resource and needs to stand alone — or the reverse — plan the change deliberately:
- Create the new classification in the correct position.
- Recreate the topics there, using the External ID to record the previous identifier so the two can be matched.
- Move or recreate records as needed.
- Archive the old classification once nothing depends on it.
This is why the tutorial advises deciding early which things stand alone.
Frequently asked questions
How deep can nesting go? Resources go one level deep, inside a data module.
Can a resource have its own record schemas? Yes. A resource is a classification, so it holds record schemas, topics and its own security policy.
Do instance counts work differently on resources? Yes — for a resource, counts apply inside each parent topic.
What does Automation do exactly? For a classification with a parent, Generate Sub-topics Automatically creates its topics when a topic is created in the parent, using the Min. Instance Count as the number. Override Sub-topic Count lets you choose a different number, even zero.
