Provisionnement pour les nouveaux employés

Mise à jour 13 mars 2026 14:34

Introduction

Le provisionnement de nouveaux employés nécessite un processus opérationnel bien défini. Vous devrez effectuer votre propre analyse, mais les flux les plus courants que nous avons observés sont soit une approche manuelle basée sur une intégration API, soit une approche assistée par SSO/SCIM qui automatise la création et la mise à jour des enregistrements d'employés dans la plateforme TrackTik. Nous réviserons les deux.

Vue d'ensemble - Approche manuelle de l'API

Les détails concernant le nouveau employé sont obtenus à partir d'une source, comme un système de ressources humaines.
These source details used to CREATE a new employee record via the TrackTik API or manually within the Guarding Suite web application are generally the same and will involve a unique identifier of some kind, like a username and/or email address.

While creating the employee, you can add additional JSON objects to the payload like address and employmentProfile information (class of employee, pay rate, ideal total work hours per week to reach, overtime rule etc.)

Your data payload to send to TrackTik may contain a temporary password that you generate in your integration software as well. POST to /employees .
Tous les employés de la plateforme TrackTik doivent avoir un rôle assigné. Ces rôles sont généralement définis au moyen de l'application Web Suite d'opérations de gardiennage, bien qu'ils puissent être créés au moyen de l'API. Chaque rôle a son propre identifiant "id" unique, qu'il faut connaître pour assigner un employé à ce rôle. Les identifiants des rôles seront obtenus au moyen d'une requête GET à partir du point de terminaison /roles. Si vous devez créer un nouveau rôle, vous pouvez le faire en envoyant un message POST à /roles.
L'employé est assigné son rôle au moyen de l'application Suite d'opérations de gardiennage ou au moyen de l'API en utilisant la valeur "id" de l'employé et la valeur "id" du rôle : POST to /user-roles.
Si l'employé est assigné à un rôle existant, ce rôle aura déjà des permissions définies pour ce qu'il peut et ne peut pas faire dans l'écosystème TrackTik (comme la visualisation des rapports pour le site de client auquel il est assigné). Si votre intégration crée des rôles, elle doit également créer des autorisations de rôle au moyen du point de terminaison /role-permissions. Il n'est pas facile de le faire soi-même, car les nombreuses fonctions du logiciel TrackTik requièrent des connaissances approfondies en matière de configuration. Vous devrez travailler avec un administrateur de votre portail Web TrackTik cible. Pour aller plus loin, un ingénieur solution TrackTik peut vous aider à réaliser une analyse d'affaires plus approfondie et un exercice de mappage de données.
Revenons aux mots de passe temporaires : Lorsqu'une inscription de base est créé, un numéro d'identification (la valeur employees.id, qui diffère de la valeur employees.customId) est renvoyé. Si la politique de confidentialité du processus métier exige que l'employé change son mot de passe pour un autre qu'il est le seul à connaître, une action est exécutée au moyen de l'API qui forcera le employé à changer son mot de passe après sa première connexion réussie sur l'application Web Suite d'opérations de gardiennage ou sur l'application mobile Ronde de garde : POST /employees/{id}/actions/force-password-change.

Si des employés, y compris les nouvelles recrues ou le personnel ayant quitté l’entreprise, rencontrent des problèmes tels qu’une absence de visibilité de leur profil ou un accès non autorisé, assurez-vous qu’ils sont correctement ajoutés ou supprimés des listes d’employés. Les profils d’employés absents de TrackTik après avoir été saisis dans Paycor peuvent nécessiter une synchronisation. Pour les rôles non employés, la fonction d’accès au portail client est recommandée.

Vue d'ensemble - Approche automatisée SSO/SCIM

If your organization is using an Identity Provider (IDP) with Single Sign-One (SSO) capabilities and features System for Cross-Domain Identity Management (SCIM), then most of the engineering efforts from the above described process won't be necessary as the IDP with SCIM capabilities will be able to integrate itself into the TrackTik ecosystem and push/sync new Employee data, and sync its Grouping solution as Roles on its own, and will handle the authentication and authorizations.

Le processus d'intégration est donc le suivant :

Pour les étapes 2 et 3 ci-dessous, la meilleure pratique consiste à configurer le SSO et le SCIM au sein du fournisseur d'identité comme une seule application, avec un seul identifiant d'application.
La fonction SSO du logiciel TrackTik doit être activée et configurée avec un échange de détails sur le système TrackTik pour l'administrateur IDP(OpenID Path) et depuis l'IDP qui aura besoin d'une création d'application dédiée(si elle n'existe pas déjà)(Client ID, Client Secret et Discovery URL). Il faut également décider quel sera le identifiant unique de l'employé, nom d'utilisateur ou adresse électronique.
La fonction SCIM du logiciel TrackTik doit également être activée, un rôle d'administrateur doit être attribué et un compte d'entité d'employé dédié au SCIM doit être créé. Le nom d'utilisateur et le mot de passe de l'inscription de l'employé dédié au SCIM de l'administrateur seront fournis, ainsi que l'ID client et le secret client d'une inscription client OAuth 2. Enfin, TrackTik fournira une adresse de point de terminaison API pour que vous puissiez demander un jeton d'accès expirant pour vous-même, qui aura une valeur d'expiration sous la forme d'un nombre de jours que vous définirez vous-même aussi.
Le fournisseur d'identité configure des groupes (rôles TrackTik) si nécessaire et y assigne des employés. Un processus de gestion est défini pour attribuer des groupes aux nouveaux utilisateurs créés dans le système.
Les détails concernant le nouveau employé sont obtenus à partir d'une source, comme un système de ressources humaines.
Ces détails sources utilisés pour CRÉER une nouvelle inscription d'employé au moyen de l'IDP SSO+SCIM impliquent un identifiant unique, tel qu'un nom d'utilisateur et/ou une adresse électronique.
Les détails de la source peuvent inclure ou non un mot de passe temporaire.
Si un mot de passe temporaire n'est pas disponible, l'intégration devra en générer un dans la couche IDP SSO+SCIM et le communiquer au nouvel employé.

Pour en savoir davantage sur nos solutions SSO+SCIM, voir "Set up Azure single sign-on (SSO) for TrackTik" et "Set up and use provisioning for Azure".

Détaillé - Approche manuelle de l'API

Créer l'employé

Créez un nouvel employé (avec un mot de passe temporaire) et prenez note de la valeur "id" attribuée dans la réponse pour l'utiliser dans les étapes suivantes :

Exemple : 1 - Base + Adresse

POST /employees

{
    "region": 2,
    "customId": "C123-A - JS",
    "firstName": "John",
    "middleName": "string",
    "lastName": "Smith",
    "primaryPhone": "555-555-1234",
    "secondaryPhone": "555-555-4321",
    "username": "johnsmith23",
    "password": "YCpE#f9^8L8az",
    "email": "john.smith23@myemail.com",
    "jobTitle": "Assistant",
    "gender": "M",
    "birthday": "1980-08-24",
    "address": {
            "addressLine1": "111 Street Ave",
            "addressLine2": "",
            "city": "Dorval",
            "country": "CA",
            "state": "QC",
            "postalCode": "H9P 1G2",
            "latitude": 45.488805,
            "longitude": -73.5859921
        },
    "language": "EN_US",
    "fax": "000-000-0000",
    "tags": 
    [
        "string1","string2","string3"
    ]
}

Exemple : 2 - Base + Adresse + Profil d'emploi

POST /employees

  {
    "region": 2,
    "customId": "C123-A - JS",
    "firstName": "John",
    "middleName": "string",
    "lastName": "Smith",
    "primaryPhone": "555-555-1234",
    "secondaryPhone": "555-555-4321",
    "username": "johnsmith23",
    "password": "YCpE#f9^8L8az",
    "email": "john.smith23@myemail.com",
    "jobTitle": "Assistant",
    "gender": "M",
    "birthday": "1980-08-24",
    "address": {
            "addressLine1": "111 Street Ave",
            "addressLine2": "",
            "city": "Dorval",
            "country": "CA",
            "state": "QC",
            "postalCode": "H9P 1G2",
            "latitude": 45.488805,
            "longitude": -73.5859921
        },
    "language": "EN_US",
    "fax": "000-000-0000",
    "employmentProfile": {
            "employeeType": "EMPLOYEE",
            "employmentDate": "2025-08-14T00:00:00+00:00",
            "payRateType": "HOURLY",
            "hourlyRateType": "EMPLOYEE_SPECIFIC",
            "hourlyRate": 48,
            "overtimeExempt": false,
            "weeklyHoursTarget": 40,
            "weeklyHoursMaximum": 0,
            "weeklyHoursMinimum": 0
        },
    "tags": 
    [
        "string1","string2","string3"
    ]
}

D'autres champs sont disponibles pour l'objet employmentProfile, consultez donc notre documentation /rest/v1 pour en savoir plus.

Sur les mots de passe

Bien que la validation de la complexité du mot de passe puisse être configurée dans l'application Web par un administrateur (non accessible au moyen de l'API), il existe des exigences minimales de base qui vous seront rappelées si vous ne les respectez pas :

Assigner un rôle (existant)

Si vous ne connaissez pas encore la valeur d'identification du rôle que vous souhaitez attribuer à l'employé, vous pouvez consulter les rôles actuels avec GET /roles . Une fois que vous avez trouvé l'identifiant, vous devez créer une inscription de jointure entre la valeur employee.id et la valeur role.id au moyen de /user-roles :

POST /user-roles

{
  "user" : 1525,
  "role" : 12
}

Créer un nouveau rôle

Vous pouvez également créer un NOUVEAU rôle. La suite d'applications TrackTik gère les autorisations par le biais de trois niveaux différents : portail administration, portail personnel, et portail client. Vous pouvez également définir l'ordre de tri de la liste des rôles dans l'application Web Suite d'opérations de gardiennage.

Portée régionale ou mondiale

Les rôles font partie d'une portée régional d'accès aux données, comme d'autres objets que vous connaissez peut-être, tels que les employés et les modèles de rapport. Si vous avez l'intention de créer un rôle non global (l'accès aux données sera limité à une région), vous devrez connaître l'identifiant de la région (qui peut être obtenu par un appel GET /regions) à inclure dans la charge utile.

Les rôles peuvent également être définis comme globaux et donner accès aux données dans l'ensemble du portail.

Dans l'exemple ci-dessous, nous allons créer un rôle de portail administrateur global (afin de répondre à un scénario d'intégration large avec un niveau d'accès plus élevé, ce qui signifie qu'un ID de région n'est pas nécessaire). Nous ne nous soucierons pas non plus de l'ordre de tri :

POST /roles

{
    "name": "API Service Account",
    "description": "For an HR system integration",
    "portal": "ADMIN",
    "order": 0,
    "account": null,
    "region": null,
    "isGlobal": true,
    "status": "ACTIVE"
}

La réponse de cette charge utile POSTée comprend un numéro d'identification attribué au rôle. Prenez-en note pour la prochaine section qui expliquera comment créer des autorisations de rôle :

{
        "name": "API Service Account",
        "description": "For an HR system integration",
        "portal": "ADMIN",
        "order": 0,
        "account": null,
        "region": null,
        "isGlobal": true,
        "status": "ACTIVE",
  ==>   "id": 53
}

Si vous préférez qu'un administrateur de l'application Web TrackTik crée le rôle pour vous, vous pouvez le faire en suivant les instructions fournies ici : https://soutien.tracktik.com/hc/en-us/articles/1500001735462--Roles-and-Permissions

Créer des autorisations de rôle

Il existe deux formats d'inscription de permission de rôle dans l'écosystème TrackTik. La première est héritée et liée à l'interface utilisateur de l'application Web, et nous ne l'utiliserons pas. Il se présente sous la forme suivante : "path/to/function". Un exemple concret serait : "patrol/customer/reports".

L'ancien format est accessible et utilisable au moyen de l'API, mais il ne suit pas un modèle suffisant pour être facilement enseigné. Si vous devez adopter cette approche, définissez les autorisations de rôle au moyen de l'application Web, comme expliqué ici : https://soutien.tracktik.com/hc/en-us/articles/1500001735462--Roles-and-Permissions

Le nouveau format est basé sur le paradigme des portails Administrateur|Personnel|Client et fait directement référence aux points de terminaison de l'API, comme "admin:employees:view" (pour l'accès en lecture au point de terminaison des employés) ou "admin:employees:create" (pour l'accès à la création d'un nouvel employé) ou un modèle de caractères génériques (astérisque) d'autorisations qui signifie "toutes les vues/créations et /method/execute" (execute est pour les actions de l'API), comme :

admin:employees:*

C'est le format que nous utiliserons dans l'exemple ci-dessous pour créer une autorisation de rôle. Si vous souhaitez que votre rôle personnalisé pour une intégration basée sur l'API accorde un accès total aux données des employés, vous devez vous souvenir de l'ID du rôle et du format de création d'une autorisation de rôle comme suit :

POST /role-permissions

{
   "role" : 53,
   "permission" : "admin:employees:*"
}

Mais si vous vouliez une autorisation en lecture seule, vous le feriez :

POST /role-permissions

{
   "role" : 53,
   "permission" : "admin:employees:view"
}

Il est possible de verrouiller les choses beaucoup plus, même jusqu'aux propriétés individuelles d'un objet de données comme les employés, et ce information sera documentée à une date ultérieure et référencées ici.

Forcer un changement de mot de passe

Lorsque vous avez besoin qu'un nouvel employé ou un employé existant définisse un nouveau mot de passe, vous pouvez forcer un mécanisme de changement de sorte que la prochaine fois qu'il se connectera à une application TrackTik en utilisant son information d'identification existant, il sera invité à définir un nouveau mot de passe. Ce statut de compte et ce processus sont déclenchés à l'aide d'une action API dédiée et tout ce dont vous avez besoin est l'identifiant de l'employé (que vous pouvez consulter au moyen de GET /employees) :

POST /employees/{id}/actions/force-password-change

(aucune charge utile n'est requise)

Vérification de l'état d'attente de la modification du mot de passe

Si vous avez besoin de générer une liste d'employés qui ont été signalés pour réinitialiser leurs mots de passe, vous pouvez appeler le point de terminaison /employees avec le filtre suivant :

GET /employees?forcePasswordChange=true

Changements de région des employés

Si vous faites une erreur et que votre employé a été créé dans la mauvaise région, vous pouvez utiliser sa valeur d'identification et la valeur d'identification de la région dans laquelle il devrait se trouver pour l'y déplacer :

POST /employees/{employees.id}/actions/move-to-region

{
   "region" : 123
}

Pour en savoir plus

D'autres opérations sur les employés vous permettent de corriger des erreurs ou d'ajouter des assignations relationnelles supplémentaires. Pour en savoir plus, consultez notre documentation OpenAPI et notre documentation Zendesk API.