Scénario Personal
Ce que fait ce scénario
Synchronise les informations personnelles du salarié.
C'est le scénario qui crée un nouveau salarié dans Nmbrs lorsqu'une personne commence dans HiBob,
c'est pourquoi tous les autres scénarios en dépendent.
Avant de commencer
- L'autorisation HiBob est configurée (voir le HiBob Authorization Guide).
- L'autorisation Nmbrs est configurée (voir le Nmbrs Authorization Guide).
- Debtor + Company sont configurés dans l'onglet Configuration de l'interface.
Configuration
Une démonstration de la configuration par un ingénieur BrynQ
Cet enregistrement reflète un instant donné ; l'interface BrynQ ou le modèle a pu légèrement évoluer depuis.
Étape 1 : Vérifiez la clé unique
Concepts clés :
Résumé
La clé unique est constituée des champs utilisés pour identifier chaque salarié lors de la comparaison entre HiBob et Nmbrs.
Grâce à la clé unique, l'interface détermine s'il faut créer ou mettre à jour ce salarié dans Nmbrs.
Important :
Si les deux systèmes contiennent déjà des données salariés, assurez-vous que les valeurs de la clé unique correspondent exactement avant d'activer l'interface. L'interface traite une valeur de clé différente comme un tout nouveau salarié, et non comme une mise à jour.
Dans BrynQ, vous pouvez vérifier la clé unique en regardant l'enregistrement dont la clé est surlignée en bleu.
La configuration standard (recommandée)
Par défaut, la clé unique est le champ HiBob Employee ID, situé dans la section Work du profil du salarié.
Dans Hibob, il correspond à ce champ :
Dans Nmbrs, il correspond à ce champ :
Ce que vous devez faire :
Avec cette configuration, vous n'avez rien à faire dans BrynQ.
Pour les systèmes déjà alimentés, vérifiez simplement que l'Employee ID HiBob correspond au numéro de salarié Nmbrs pour chaque salarié.
Astuce : pour faire correspondre les salariés entre les deux systèmes, utilisez un champ commun comme l'adresse e-mail ou le BSN comme référence. C'est suffisant pour une vérification ponctuelle.
Configuration personnalisée : quand s'écarter de la configuration recommandée
Il peut arriver que le champ 'Employee ID' de Hibob ne convienne pas à votre environnement et que vous ayez plutôt créé un champ personnalisé dans Hibob pour identifier chaque salarié de façon unique.
Cela peut être le cas si votre environnement couvre plusieurs entités et que vous avez besoin d'un identifiant personnalisé commun.
Dans ce cas, suivez les étapes suivantes dans BrynQ :
- Supprimez 'Work Employee ID' en cliquant sur la croix.
- Changez le type de champ source en custom.
- Sélectionnez le champ personnalisé comme clé primaire.
FAQ
1. Pouvons-nous utiliser d'autres champs standard, comme l'e-mail, comme clé unique ?
Non, utilisez toujours un champ dédié dans Hibob qui correspond au champ "employee number" de Nmbrs.
2. Pourquoi ne pouvons-nous pas utiliser un autre champ standard Hibob et un autre champ Nmbrs pour identifier les salariés de façon unique ?
Les autres champs ne sont pas des identifiants fiables. Par exemple, les adresses e-mail ne sont pas fiables car leur domaine peut changer.
De même, une faute de frappe ou une différence de format dans le BSN pourrait entraîner la création de nouveaux salariés, ce qui n'est pas le résultat souhaité.
3. Que dois-je faire si j'utilise les champs standard et que mes données de clé unique sont alignées ?
Rien, tout est prêt.
Étape 2 : Vérifiez les mappages de valeurs (brouillon à partir d'ici)
Les mappages de valeurs traduisent un libellé HiBob en code attendu par Nmbrs. Ils se trouvent sur chaque enregistrement de ce scénario et sont pré-remplis par BrynQ.
Enregistrements avec un mappage de valeurs : Gender, Nationality.
Ne modifiez un mappage de valeurs que si le rapport d'exécution signale une valeur non mappée. C'est le seul signe que le mappage présente une lacune pour vous.
Exemples typiques de mappages de valeurs. Il s'agit de paires entrée-sortie fictives pour illustrer le format ; le mappage de votre interface est défini par BrynQ lors de l'onboarding et peut contenir plus ou moins d'entrées.
personal_nationality dans HiBob → nationality_code_iso dans Nmbrs
American | → | US |
Australian | → | AU |
Basotho | → | LS |
Belarusian | → | BY |
Belgian | → | BE |
Bissau-Guinean | → | GW |
Brazilian | → | BR |
British | → | GB |
(d'autres paires entrée-sortie apparaissent généralement ; ouvrez l'onglet Mapping de l'interface pour la liste complète.)
home_legal_gender dans HiBob → gender dans Nmbrs
Female | → | female |
Male | → | male |
Non-binary | → | unspecified |
Other | → | unspecified |
(d'autres paires entrée-sortie apparaissent généralement ; ouvrez l'onglet Mapping de l'interface pour la liste complète.)
Ce qui se passe en coulisses
Voici ce que le scénario fait entre HiBob et Nmbrs, au-delà d'une simple copie. Vous ne les configurez pas (ils sont intégrés au modèle), mais les connaître vous aide à comprendre ce que vous voyez dans le rapport d'exécution.
Certaines lignes sont filtrées
- Le scénario ignore les lignes qui n'auraient pas de sens dans Nmbrs (par exemple, les salariés hors paie ou les contrats annulés avant leur début).
Les salariés continuent d'être synchronisés même si une valeur manque
- Le scénario écrit quand même l'enregistrement, même si la valeur source est vide ou non reconnue. La valeur manquante est signalée, mais le reste des données du salarié est bien transmis.
La valeur est complétée lorsque HiBob la laisse vide
- Lorsque HiBob ne fournit pas de valeur, le scénario écrit une valeur par défaut cohérente afin que Nmbrs accepte tout de même l'enregistrement.
La valeur est découpée avant d'être envoyée
- Le scénario découpe une chaîne HiBob en plusieurs éléments distincts stockés par Nmbrs (par exemple la ligne d'adresse en rue, numéro et complément).
Valeurs que ce scénario écrit toujours, quelle que soit la valeur dans HiBob
Certains champs cibles de Nmbrs sont fixés par le modèle. Vous ne les définissez pas : ils reflètent la manière dont BrynQ recommande de structurer Nmbrs pour une interface pilotée par HiBob.
| Employee Type | = | payroll |
| Ascription Code | = | 1 |
Quand modifier un mappage
Les modifications de mappage sont généralement déconseillées : le modèle est déjà configuré comme BrynQ le recommande pour HiBob et Nmbrs. Il existe quatre situations où une modification est réellement justifiée :
- Le champ HiBob standard lu par l'enregistrement ne convient pas à votre configuration. Pointez l'enregistrement vers un autre champ standard via le sélecteur de source de l'enregistrement.
- Aucun des champs standard de HiBob ne convient et vous avez besoin d'un champ personnalisé. Ajoutez d'abord le champ personnalisé dans HiBob, puis remplacez la source de l'enregistrement.
- Nmbrs n'a pas besoin de ce champ pour votre entreprise. Si la cible est facultative dans Nmbrs, supprimez l'enregistrement. Consultez About Records pour savoir comment supprimer proprement un enregistrement.
- Il manque un champ dont Nmbrs a besoin. Ajoutez un nouvel enregistrement. About Records explique la marche à suivre.
Les étapes détaillées pour ajouter, modifier et supprimer des enregistrements se trouvent dans About Records - How to map fields inside a scenario.
La modification d'une clé unique entraîne un nouvel appariement de tous les enregistrements existants lors de la prochaine exécution ; ne faites jamais cela sur des données de production.
Tests et validation
À quoi ressemble un résultat 'terminé'
- Les nouveaux salariés HiBob apparaissent comme nouveaux salariés dans Nmbrs après l'exécution.
- Le champ BSN de la fiche salarié Nmbrs correspond à la valeur dans HiBob.
- Le rapport de comparaison ne montre aucune ligne 'edited' inattendue pour des données stables.
Ne testez jamais sur une entreprise Nmbrs de production ; utilisez une entreprise de Démo jusqu'à ce que la comparaison soit propre.
Pourquoi l'envoi d'un BSN échoue-t-il alors que la valeur semble valide ?
La raison figure toujours dans le journal d'exécution de cet enregistrement. Nmbrs applique sa propre validation (longueur, somme de contrôle, formats autorisés) et rejette tout BSN qui ne la passe pas. Consultez le message de rejet exact de l'enregistrement en échec plutôt que de supposer un problème de mappage ; les problèmes de mappage apparaissent plus tôt et produisent d'autres erreurs.
Pourquoi Nmbrs renvoie-t-il parfois l'erreur 'employee number already exists' ?
Nmbrs conserve les salariés inactifs et leurs numéros restent réservés. Lorsque l'interface tente de (re)créer l'un d'eux, Nmbrs renvoie 'already exists'. L'interface ignore cet enregistrement avec un message clair au lieu de réessayer. C'est à vous de décider de réactiver l'enregistrement Nmbrs ou d'attribuer un nouveau numéro.
Comment le BSN est-il nettoyé avant son envoi vers Nmbrs ?
Les BSN provenant de HiBob sont automatiquement formatés avant d'être envoyés à Nmbrs : des zéros sont ajoutés si la valeur compte moins de neuf chiffres, et les traits d'union sont supprimés. Par exemple, un BSN enregistré sous la forme '12-345-678' devient '123456780'.
Que couvre le thème Personal ?
Personal synchronise les champs d'identité (nom, genre, BSN, nationalité, date de naissance, date d'entrée) de HiBob vers Nmbrs. Il s'exécute en premier, car les thèmes suivants supposent que le salarié existe déjà dans Nmbrs. Au passage, les BSN sont nettoyés, la particule et le nom de famille sont séparés, la nationalité est traduite à l'aide du mappage de valeurs et les initiales sont déduites du prénom.
Articles associés
- FAQ
- Set Up Scenarios in a Template Interface
- About Scenarios - Organizing your interface into topics
- Set Up Scenarios in a Template Interface
- About Records - How to map fields inside a scenario
Sources