Every organization has records that nobody is responsible for: the customer file that three people touch and none of them owns, the property whose problems get reported but never picked up. Atlas makes that situation visible — and fixable — through topic ownership.
What ownership means in Atlas
In Atlas Enterprise, a topic is one individual thing — one property, one customer, one piece of equipment. A topic is owned by a user group: the team that answers for it.
Ownership is tied to the Manage access level. Manage makes a user group answerable for something, which is how Atlas knows whose work it is. It’s the only level that’s always given to a user group rather than a role or a single user. See The five access levels.
Unassigned Topics
Topics created by an administrator belong to no user group. Atlas collects them under Unassigned Topics in the navigation, each marked as waiting for an owner. From there, Assign a group binds a topic to the team that will answer for it.
The Atlas tutorial explains why this matters: a topic nobody manages is a problem, because the work it raises reaches nobody.
The warning on data modules
Ownership shows up on classifications, too. When you look at a top-level data module’s access rights, Atlas warns if there’s no user group with Manage access, because that’s the group its work is raised to. It’s a nudge to decide ownership at the module level before topics pile up.
Why ownership belongs in the data model
In many systems, responsibility lives outside the data — in someone’s memory, a spreadsheet of assignments, or an email thread. When that’s the case:
- Work goes to a person, not a team, and stalls when that person is away.
- Nobody notices orphaned records until something goes wrong.
- Handoffs are informal, so they’re easy to drop.
Putting ownership in the model means every topic is either owned or visibly unowned. Atlas’s operations features build on the same idea: its work queues are scoped to roles rather than individuals, so nothing silently lands in one person’s inbox.
Habits that keep ownership clear
- Decide the owning group before you create a data module. Give it Manage access on the module’s policy or as an explicit rule.
- Check Unassigned Topics regularly. Treat it as an inbox that should be empty.
- Assign to teams, not people. User groups survive vacations and reorganizations; individuals don’t.
- Name groups for the work they own — North Region Crew, Office Staff — so it’s obvious where a topic belongs.
- Revisit ownership when the business changes. A new region or team usually means new groups and reassigned topics.
Setting up ownership from the start
Ownership is easiest when it’s decided before topics exist:
- Create user groups that match how work is divided — by region, team or function.
- Give the responsible group Manage access on each data module, either through the module’s security policy or as an explicit rule.
- Assign topics as they’re created, rather than letting them accumulate unowned.
- Check Unassigned Topics weekly and treat it as an inbox that should be empty.
What ownership does and doesn’t mean
Ownership means a named team answers for a topic: its records are their responsibility, and work raised against it reaches them.
Ownership doesn’t mean exclusive access. Other roles can still discover, read or write a topic if the security policy allows. Responsibility and visibility are separate questions — see The five access levels.
A worked example
Evergreen Landscaping divides its work by region. It creates two user groups: North Region Crew and South Region Crew.
- The Service Properties data module’s policy gives office staff Read and Write, and each crew Discover and Read.
- Each property topic is assigned to the crew group that services it, giving that group Manage.
- When a service request raises work on a property, it reaches the crew responsible, not a general inbox.
- When a property changes region, the topic is reassigned to the other group — one change, no other edits needed.
Common mistakes
- Assigning to individuals. Work stalls when that person is away.
- Creating a group per topic. Groups should match teams, not things.
- Leaving Unassigned Topics to grow. It becomes a backlog nobody reviews.
- Confusing ownership with access. A team can own topics that many other roles can read.
Frequently asked questions
Who can assign a topic to a group? Assignment is done from Unassigned Topics, within your organization’s permissions.
Can a topic change owner? Yes — reassign it when responsibility moves.
Why is Manage restricted to user groups? Because responsibility belongs to a team. Atlas locks the grantee type to Group when you choose Manage.
What if no group should own something yet? It stays in Unassigned Topics, which is exactly the point: it’s visible as unowned rather than silently ignored.
Ownership and handover
Ownership matters most at moments of change:
- New team or region. Create the group first, then reassign the topics that belong to it.
- A team splits. Decide the dividing line — by geography, customer or asset type — and reassign in one pass.
- A team is dissolved. Reassign its topics before removing the group, so nothing is left unowned.
- Seasonal work. If responsibility shifts between seasons, plan the reassignment as part of the seasonal changeover.
In every case the work is the same: change the owning group on the affected topics. Because responsibility lives in the data rather than in habit or memory, the handover is explicit and complete.
The bigger idea
Ownership is a small field with a large effect. When every record has a team that answers for it, reports have someone to act on them, customers have someone to follow up, and work raised in Atlas always reaches somebody. For the broader practice, see Data governance for teams without a data team.
