Il s'agit d'un formulaire simple que les chefs de service, par exemple, peuvent utiliser pour demander la création d'un compte utilisateur pour des personnes externes, telles que des consultants, des intérimaires, des étudiants, etc. Ce processus ne nécessite pas d'approbation, mais impose de définir une date d'expiration pour le nouveau compte utilisateur.
Flux de travail
1. Mise en page du formulaire
Nous avons utilisé Storylane pour créer un guide expliquant comment créer ce formulaire :
Nous vous recommandons de veiller à ce que le formulaire que vous créez comporte les mêmes champs obligatoires que notre exemple. Les champs obligatoires sont signalés par un astérisque rouge :
2. Modèle de synchronisation
Une fois le formulaire envoyé, il servira à créer manuellement les données source du nouveau compte utilisateur. Cette opération s'effectue à l'aide d'un modèle de synchronisation spécifique, que vous devrez également créer (ou copier à partir d'un ensemble de modèles, si vous y avez accès).
Paramètres :
-
Nom : Identique à celui du formulaire
-
Actif : Oui
-
Type d'objet : Données de formulaire
-
Étape de synchronisation : objets manuels de l'eHUB vers l'eADM
Ensemble de règles :
Vous devez créer un ensemble de règles de type « Données de formulaire » portant le même nom que le formulaire, et la règle doit être la suivante : Form ID = ID du formulaire que vous avez créé à l'étape 1.
Mappages d'exportation
Les mappages d'exportation suivants sont recommandés :
|
Source |
Cible |
|---|---|
|
Commune d'Utfjord |
Entreprise |
|
[Prénom] [Nom] |
Nom d'affichage |
|
[HASH;[SourceId]] [SourceId] |
SourceId |
|
[Numéro de sécurité sociale] |
Numéro de sécurité sociale |
|
[RÉFÉRENCE ; Service ; Numéro du service ; 2 ; [Numéro du service]] |
Département |
|
[Numéro du service] |
Numéro de service |
|
[Date d'approbation] |
Démarrer |
|
[Prénom] |
Prénom |
|
[HASH;[SourceId]] |
Numéro d'employé |
|
[Date d'expiration] |
Arrêt |
|
[Date d'expiration] |
Date d'expiration |
|
[Date d'approbation]| |
APositionStartDate |
|
[Numéro du service]| |
Numéro du service parent |
|
Vrai| |
APrimaryPosition |
|
[Date d'expiration]| |
Date de fin du poste |
|
[RÉFÉRENCE ; Responsable ; Numéro du service ; 2 ; [Numéro du service]] |
Responsable |
|
[REFERENCE;Numéro d'unité organisationnelle;Numéro de service;2;[Numéro de service]]| |
AUnitId |
|
[RÉFÉRENCE ; Service ; Numéro du service ; 2 ; [Numéro du service]]| |
NomDeL'unité |
|
[ExtensionAttribute1]| |
APositionCodeName |
|
Vrai |
Fusion manuelle |
|
[ExtensionAttribute1]| |
Nom du type de poste |
|
[Mobile] |
PrivatePhone |
|
[ExtensionAttribute1] |
Titre |
|
[E-mail] |
E-mail privé |
|
[Nom de famille] |
Nom de famille |
|
[RÉFÉRENCE ; Service ; Numéro du service ; 2 ; [Numéro du service]]| |
Département parent |
Création et intégration d'un utilisateur
À moins que les utilisateurs externes ne soient expressément exclus des règles relatives aux flux de communication, à la gestion des accès et à l'attribution des licences, ils bénéficieront des mêmes droits d'accès, licences, comptes de messagerie, etc. que les employés internes du même service et suivront les mêmes flux de communication que ces derniers lors de leur prise de fonction. Il est recommandé d'effectuer un test afin de vous assurer qu'aucun droit que vous ne souhaitez pas accorder aux collaborateurs externes ne leur est attribué.
NB ! Si vous effectuez une exportation vers AD, vous devez ajouter une sous-règle dans le modèle de synchronisation pour les utilisateurs actifs, afin de limiter l'exportation des numéros d'employé aux seuls numéros reçus de HRM. La règle est simple : « utilisateur manuel » n'est pas vrai.