Overview
Deleting a Location and deleting a Location Group have different effects. Before removing either, identify the work and access that depend on it and decide whether deletion is actually the change you need.
Use this checklist when retiring a Location, removing a duplicate group or reorganizing your Location hierarchy.
At a glance |
|
Who can do this | Super Users, authorized creators, or Locations › Delete / Location Groups › Delete, as applicable. |
Where | Locations and Location Groups |
Works on | Backend (web) |
Availability | All organizations |
💡 Why this matters: Locations and Location Groups are used beyond the list where you delete them. Reviewing those connections helps prevent interrupted work and unexpected access changes.
Choose the intended change
Your aim | Start here |
Stop one Checklist at a Location | Review the Schedule’s targets or exclusions. |
Change who can access a Location | Review direct and inherited membership. |
Retire the Location itself | Review its dependencies before deleting it. |
Remove a group hierarchy | Review the group and every descendant group. |
If the goal is only to stop scheduled work, edit the relevant Schedule instead. A Location may receive work through a Location Group, so removing one direct selection may not remove every targeting route. See scheduling prerequisites and how access works.
Understand the deletion scope
🛑 Critical: Deleting a Location Group also deletes its descendant Location Groups. Check the whole branch before confirming. There is no normal undo step for rebuilding that hierarchy and its references.
Deleting a Location Group removes the group’s relationships with its Locations; it does not delete those Locations themselves. Membership inherited through that hierarchy can change.
Deleting an individual Location removes it from Location Groups and updates affected Schedule targets and exclusions. It is not a merge with another Location, and creating another Location with the same name is not a history transfer.
For the deletion controls and permission rules, see Locations and Location Groups.
Review dependencies first
Area | What to review |
Schedules | Direct and group targets, exclusions, and work already underway. |
Memberships | Users or User Groups receiving access through the hierarchy. |
Notifications and reports | Targeted Result reports, Activity Summaries and Work Forecasts. |
Library content | Location Group limits on Manual, Video and Link versions. |
Historical records | How required Results, Assignments and operational records will be found after the change. |
Deletion updates affected Calendar occurrences whose end time is still in the future. Some of those may already have started, so plan the change with the teams doing the work.
Removing a Location Group also removes references to it from affected Library versions. Recheck their remaining target restrictions before the change, especially where that group was the only limit.
Historical Results and Assignments are not automatically merged into another Location. Do not rely on deleting a Location as a way to remove its history or to preserve exactly the same reporting filters. Ask Support to confirm your retrieval needs before deleting a Location with important records.
Prepare and verify the change
1. Record the current setup
Keep the affected Location and group names or links, the group hierarchy, Schedule targets and any required historical reports. Identify which administrator owns each shared configuration.
2. Plan the replacement relationships
If work or access should move elsewhere, prepare the intended Schedule and membership changes explicitly. Check who will receive work at the replacement Location; matching names do not establish matching configuration.
3. Check the result afterwards
After the authorized change, inspect the affected Schedules, group memberships, notification rules and Library limits. Confirm that the intended teams can find their work and that required reports remain retrievable.
Best practices
Prefer a targeted Schedule or membership change when that is the actual goal.
Review every descendant before deleting a Location Group.
Confirm historical reporting needs before retiring a Location.
Frequently asked questions
Will deleting a Location remove all its Checklist and Assignment history?
Do not use Location deletion as a history-deletion tool. It does not merge old records into another Location. Confirm how you will retrieve required historical Results and Assignments with Support before removing the Location.
Can we delete a Location after creating it?
Yes, with the appropriate deletion access. Review its dependencies first; see Locations for the controls and limitations.
How do I remove one Location from a Schedule?
Review the Schedule’s target Locations, Location Groups and exclusions. Change the Schedule’s scope rather than deleting the Location; see scheduling prerequisites.