Avant de commencer
Si vous mettez en place Poplee Socle RH pour un client avec différentes entités étrangères, ou si vous ajoutez une entité étrangère à une instance, vous êtes probablement confrontés à plusieurs problématiques :
- Certaines données ne doivent pas être disponibles pour tous les pays
- Une donnée peut être obligatoire pour certaines populations mais pas d'autres
- Les admins régionaux ne doivent voir que leur population et par conséquent que les données de cette population
- Les procédures d'onboarding et d'offboarding, le paramétrage des alertes sont différents
Certaines de ces problématiques peuvent être adressées. Cette fiche d'aide a pour objectif de proposer le paramétrage optimal pour y répondre tout en explicitant les limites restantes.
Comment paramétrer des données spécifiques à certains pays ?
Poplee Socle RH ne propose pas le concept de "réglementaires" comme d'autres solutions Lucca. Ce concept permet de définir un ensemble de règle applicables à une liste d'établissement. On peut toutefois reproduire ce même comportement à travers la création de sections spécifiques et une configuration des rôles particulière.
Créer des sections par établissement / population
Les droits d'accès en lecture et en modification se font au niveau des sections, et non des données. La première étape consiste donc à créer des sections spécifiques par pays / population à partir du moment où elles contiennent des données qui ne doivent être disponibles qu'à une population.
Vous aurez donc potentiellement une section contenant 10 données communes à l'ensemble de l'instance, mais une donnée supplémentaire est nécessaire pour un pays uniquement. Il faudra donc créer la section avec les 10 données communes, la dupliquer et y ajouter la donnée supplémentaire. N'oubliez pas de la préfixer / suffixer avec la population cible pour faciliter votre paramétrage.
Vous devez faire de même pour toutes les sections.
Créer des rôles secondaires par population
Si vous paramétrez un seul rôle pour un admin qui a accès à plusieurs pays, vous rencontrerez le problème suivant : lorsque l'admin se rendra sur le dossier RH d'un collaborateur de la population A, il verra également les sections spécifiques à la population B, ce qui n'est pas souhaitable. Par ailleurs, les données incomplètes de ces sections "non souhaitées" s'afficheront comme manquantes si elles sont cochées comme obligatoires.
L'idée est donc de créer un rôle secondaire par population. Ce rôle sera rattaché à un établissement uniquement (UK par exemple), et permettra de voir / modifier uniquement les sections pertinentes à cette population.
Vous pourrez conserver les autres permissions de configuration au niveau du rôle principal.
NB : si plusieurs établissements présentent strictement la même configuration du dossier RH, vous pouvez créer un seul rôle qui donne accès à ces établissements.
Affecter les rôles secondaires aux admins selon leur périmètre de gestion
Une fois les rôles paramétrés, il conviendra de les affecter aux admins. Si un admin ne gère que le UK, il n'aura donc que ce rôle secondaire, et un admin général aura tous les rôles secondaires nécessaires.
Cela permettra alors de s'assurer qu'un admin qui a accès à toutes les populations verra uniquement les sections du collaborateur sur lequel il se trouve. Et les données incomplètes dans les sections des autres populations ne seront pas marquées comme manquantes car techniquement, l'admin n'aura pas le droit de les consulter pour ce collaborateur.
Les limites qui subsistent
Avec le paramétrage proposé ci-dessus, les administrateurs auront la sensation d'avoir des dossiers RH différents selon la population.
En revanche, il reste toutefois quelques problèmes d'étanchéité, surtout au niveau des objets de configuration.
Toute personne ayant accès à la configuration du dossier RH verra l'ensemble des sections et des données, y compris celles qui ne le concernent pas. Il y a donc un risque qui les modifie par erreur, impactant le paramétrage des populations voisines.
Le problème est le même avec l'onboarding, où tous les modèles sont visibles de tous les administrateurs.
Pour limiter cette problématique, il est recommandé de ne donner accès au paramétrage qu'à un admin central. Cette recommandation est valable pour l'ensemble des solutions Lucca.