Overview
Moving a region, site, or branch to a different parent region changes the hierarchy and can impact inherited configurations, user access, and certain operational dependencies. Proper preparation and validation are essential to ensure a smooth transition with minimal disruption.
Key Principles
- Region-contained data remains intact: Assets such as sites, zones, licenses, tours, and similar objects typically stay unaffected because they are stored within the region itself.
- Inherited data may be impacted: Any configuration pushed from a parent to a sub-region may be lost or changed after the move.
- Access is hierarchy-dependent: User visibility and permissions can change if they rely on the previous parent structure.
Potential Impacts
1. Inherited Configurations
Changing a parent region can affect settings inherited from that parent, including:
- Custom roles and permissions
- Report templates and scheduled reports
- Incident categories and related structures
- Dispatch workflows and job types
- Calendar groups and pay codes
- Site or zone templates
If these are defined at the original parent level, they may no longer be available after the move unless replicated in the target parent.
2. User Access and Visibility
- Users with roles scoped to a specific region hierarchy may lose or gain access after the move.
- Access must be reviewed and reassigned if it depended on the original parent region.
- Reporting views, dashboards, and saved filters based on region hierarchy may require updates.
3. Operational Dependencies
Certain operational elements may depend on region-level configurations:
- Patrol routes and tours may rely on region-specific zones
- Automations, notifications, and escalation rules may filter by region
- Scheduled reporting may be tied to the original region path
These dependencies should be identified and adjusted as needed.
4. Integrations and External References
- APIs, exports, webhooks, and integrations that reference region identifiers or hierarchy paths may require updates after the move.
Pre-Move Preparation Checklist
Before performing the move, complete the following:
Audit Parent Region Configuration
- Review all settings in the current parent region
- Identify any configurations shared with sub-regions
- Document or export:
- Roles and permissions
- Report templates
- Incident categories and configurations
Compare Target Parent Setup
- Verify whether equivalent configurations exist in the target parent
- Plan to replicate or align missing elements if needed
Review Dependencies
- Validate tours, zones, and checkpoints
- Identify automations or notifications using region filters
- List scheduled reports and integration dependencies
Plan User Access Adjustments
- Identify users affected by the hierarchy change
- Prepare updates to roles and permissions post-move
Communication and Timing
- Schedule the change during a low-impact window
- Notify stakeholders and impacted users in advance
Backup and Testing
- Export critical configurations and mappings
- If possible, test the move in a staging environment
Move Procedure
- Pause Time-Sensitive Processes
- Temporarily disable automations, notifications, and scheduled reports related to the region
- Change Parent Region
- Update the parent region in the system configuration
- Reconcile Configurations
- Reassign roles and permissions
- Reapply required report templates and incident categories
- Reconnect Operational Elements
- Validate tours, zones, and checkpoints
- Adjust mappings if necessary
- Update Integrations and Rules
- Modify filters, region references, and external configurations
- Resume Operations
- Re-enable automations and reporting processes
Post-Move Validation
Within 24–48 hours, verify:
- Access: Ensure users have correct visibility and permissions
- Operations: Test tours, checkpoints, and workflows
- Incidents: Confirm proper categorization and reporting
- Reports: Validate scheduled reports and recipients
- Integrations: Confirm external systems are functioning correctly
Rollback Considerations
If critical issues occur:
- Revert the region to its original parent
- Restore previously exported configurations
- Re-enable original automations and reporting
- Communicate the rollback to stakeholders
Summary
Moving a region or site is generally low-risk for core data stored within the region itself. However, inherited configurations, access control, and integrations require careful planning. A structured approach, auditing dependencies, preparing configurations, and validating outcomes ensures a seamless transition.