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.
Region entitlements
Your TrackTik agreement includes a specific number of regions you can use. This usually includes the HQ region plus a set number of additional regions. Creating more regions than your entitlement allows requires a contract update or purchase.How regions are counted:
- HQ region: Counts as one region.
- Additional regions: Each distinct operational region counts as one, whether top-level or a sub-region.
- View filters: Options like "View all regions" are views/filters and do not count toward your total.
How to check your entitlements:
- Review your Order Form/contract for region counts.
- Ask your Customer Success Manager (CSM) or open a support ticket to confirm how many regions are currently active and how many you are entitled to.
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:
- At this time, region and affiliate names are managed by support to ensure consistency across your environment and to prevent unintended downstream effects. Please submit a support ticket and we will update it for you.
- 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.