Talk to your TrackTik representative about adding regions if you operate in many places over one or multiple geographic areas. If this does not apply to your operation, your portal will have a single region.
Each region contains a unique set of configurations, such as the time zone and other settings that apply to different TrackTik BackOffice modules. Each region can also include its sub-regions, sites, zones, departments, and employees.
Talk to your TrackTik representative to see if regions are suitable for your operation. For more information about regions, please see the TrackTik BackOffice Suite manual.
Regions define the geographic hierarchy used to organize countries, areas, and sites in your portal. If you need new regions or changes to existing ones, follow the steps below to ensure they are created correctly in both SSE staging and production.
Before requesting changes, prepare the following:
- Clear description of each new region: name, short code/abbreviation, and purpose.
- Parent/child placement: indicate where the region should sit in the hierarchy (e.g., Global > Region > Country > Area > Site).
- Country coverage: list all countries that belong to the new region.
- Environment target: specify whether the change should be made in SSE staging only, or in both SSE staging and production.
- Effective date and any blackout windows for release.
- Stakeholder approvals: provide the names of approvers for the change.
- Dependencies that may be impacted: reports, dashboards, workflows, permissions, integrations, billing groupings.
To request region creation or modification:
- Submit a support ticket with the subject: “Region Hierarchy Update – [Your Org]”.
- Include the prepared details above in this format:
- Region name:
- Region code:
- Parent node:
- Countries included:
- Environments (SSE staging/prod):
- Effective date:
- Approvers:
- Impacted dependencies:
- If changes are urgent or complex (for example, splitting a region or moving multiple countries), request a brief review call in your ticket.
Implementation flow (typical):
- Staging: Regions are created in SSE staging first so you can validate structure and assignments.
- Validation: Verify the region appears in the hierarchy and that country assignments and permissions behave as expected.
- Production: Once approved, the same changes are applied to production.
Post-creation checks:
- Navigation: Go to Admin or Geography settings and ensure the region appears under the correct parent.
- Assignments: Confirm countries, areas, and sites that belong to the region are correctly associated.
- Permissions: Validate that user roles scoped to the new region behave as expected.
- Reporting: Check any reports or dashboards filtered by region continue to work and include the new region.
- Workflows: Review any automation rules or notifications that reference regions.
- Integrations: If you have API or data syncs that use region codes, verify they recognize the new values.
Best practices:
- Use consistent naming conventions (for example, APAC, EMEA, AMER) and unique region codes.
- Avoid duplicate region names or codes across environments.
- Document the change log (who requested, when deployed, what changed) for auditability.
- Test in SSE staging before promoting to production.
Based on your permissions, when viewing All Regions, you will be limited to viewing only the regions to which you are assigned.
Check out this article in our BackOffice User Manual to learn more about region-specific settings.