Discutez avec votre représentant TrackTik de la possibilité d'ajouter des régions si vous opérez à partir de plusieurs emplacements géographiques. Si cela ne s'applique pas à vous, votre portail aura une seule région.
Chaque région contient un ensemble unique de configurations, telles que le fuseau horaire et d'autres paramètres qui s'appliquent aux différents modules de la Suite de gestion administrative de TrackTik. Chaque région peut également inclure des sous-régions, des sites, des zones, des départements et des employés.
Contactez votre représentant TrackTik pour savoir si les régions sont adaptées à vos activités. Pour plus d'informations sur les régions, veuillez consulter le manuel la Suite de gestion administrative.
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.
Droits régionaux
Votre accord TrackTik inclut un nombre précis de régions que vous pouvez utiliser. Cela inclut généralement la région du QG ainsi qu’un nombre défini de régions supplémentaires. Créer plus de régions que ce que votre droit permet nécessite une mise à jour ou un achat de contrat. Comment les régions sont comptées :
- Région QG : Compte comme une seule région.
- Régions supplémentaires : Chaque région opérationnelle distincte compte comme une seule, qu’elle soit de niveau supérieur ou une sous-région.
- Filtres de vue : Des options comme « Voir toutes les régions » sont des vues/filtres et ne comptent pas dans votre total.
Comment vérifier vos droits :
- Examinez votre formulaire de commande/contrat pour les décomptes régionaux.
- Demandez à votre gestionnaire de réussite client (CSM) ou ouvrez un billet de support pour confirmer combien de régions sont actuellement actives et combien vous avez droit.
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:
- À ce moment-là, les noms des régions et des affiliés sont gérés par le support afin d’assurer la cohérence dans votre environnement et d’éviter des effets inattendus en amont. Veuillez soumettre un billet de soutien et nous le mettrons à jour pour vous.
- 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.
En fonction de vos autorisations, lorsque vous consultez Toutes les régions, vous ne pourrez consulter que les régions auxquelles vous êtes affecté.
Check out this article in our BackOffice User Manual to learn more about region-specific settings.