Names are the user interface of your data model. Good names make an Atlas workspace easy to navigate for everyone; poor ones make people guess. Every classification in Atlas has four naming fields, and each has a job.
The four fields
Name — required, and unique in your organization. The precise, formal name of the classification: Service Properties.
Key — built automatically from the name: lower case, with anything that isn’t a letter or a number turned into an underscore. Service Properties becomes service_properties. You can’t edit it; it follows the name. Keys are a stable, machine-friendly form of the name.
Label — optional. If you give one, Atlas shows it in the File System in place of the name. That lets the name stay precise while the label reads the way your team talks: Properties.
Description — required, up to 256 characters. A sentence or two for anyone who wonders what the classification is for.
Naming conventions that work
Name the things, not the tasks
The Atlas tutorials put this first: Properties and Customers, rather than Inspecting or Billing. Classifications describe kinds of things; the work done on them belongs in record schemas and pipelines.
Use plural nouns
A classification holds many topics, so a plural reads naturally in the File System: Properties, Customers, Vehicles. Individual topics then get singular, specific names: 42 Juniper Lane.
Be precise in the name, friendly in the label
If your organization has several kinds of properties, the name can disambiguate (Service Properties, Rental Properties) while each label stays short.
Choose names you won’t need to change
Because the key follows the name, it’s worth choosing a name you’ll be happy with. A name that describes what the thing is tends to last longer than one that describes a current team, project or tool.
Writing a good description
A description should answer three questions in under 256 characters:
- What is one of these? “A property we provide landscaping services to.”
- What’s kept here? “Holds each property’s profile, site surveys and service history.”
- Who uses it? “Used by field crews and the office team.”
Record schemas and topics, too
The same care applies below the classification. Record schemas need a required name and description — Property Profile, “What we keep on file for every property.” Topics need a name that identifies one individual — an address, a customer name, an asset tag — plus an optional External ID for matching with other systems. See External IDs and topic properties.
A naming style guide you can adopt
Teams that write down a short naming convention avoid years of inconsistency. A starting point:
- Classifications: plural nouns describing things — Customers, Properties, Vehicles.
- Resources: plural nouns describing what belongs to a parent — Site Surveys, Maintenance Visits.
- Record schemas: singular, describing what’s kept — Property Profile, Visit Report.
- Data schemas: the information group — Contact Details, Service Address.
- Topics: whatever identifies one individual — an address, a customer name, an asset tag.
- Labels: the shortest term your team uses in conversation.
Worked examples
| Name | Label | Description |
|---|---|---|
| Service Properties | Properties | A property we provide landscaping services to. Holds its profile, surveys and service history. |
| Commercial Customers | Customers | Businesses we invoice. Holds contact details and billing information. |
| Fleet Vehicles | Vehicles | Trucks and trailers we operate. Holds registration, maintenance and inspection records. |
Each name is precise enough to be unique, each label is short enough to scan, and each description tells a newcomer what belongs there.
What makes a name age badly
- Tool names. A classification named after software you use today will be wrong when you change tools.
- Team names. Teams reorganize more often than the things they look after.
- Project names. “Q3 Rollout Properties” will still be there in three years.
- Abbreviations. Svc Props saves a few characters and costs everyone a moment of translation.
Frequently asked questions
Can two classifications have the same name? No — the name must be unique in your organization. Labels don’t have to be unique, which is another reason to keep names precise.
What if I need to rename something? Names can be edited; remember the key follows the name.
Should the label always differ from the name? No. Give a label only when the name is longer or more formal than what your team says day to day.
Does the description appear anywhere useful? It’s shown to anyone looking at the classification, which makes it the cheapest onboarding documentation you’ll ever write.
Naming in a growing organization
Names that work for a five-person team can strain at fifty. Two habits keep them useful as you grow:
Prefix by domain only when you must. If two teams both track “Requests” for different purposes, Service Requests and Supply Requests are clearer than a shared name with a note. Avoid prefixing everything pre-emptively — it makes short lists harder to scan.
Keep a short naming register. One page listing each classification, its label and one sentence of purpose. New team members read it in five minutes, and it stops the slow accumulation of near-duplicate names. The required description field means much of this documentation already exists inside Atlas; the register simply gathers it in one view.
Review names when the business changes. A merger, a new service line or a reorganization is the right moment to check that names still describe what the business tracks.
A quick naming review
Before creating a classification, read its name and label aloud as a teammate would see them in the File System. If a new hire could guess what’s inside, you’ve named it well.
