Les rôles


Definition

Un rôle est une variable dynamique permettant d'assigner des actions à un ou plusieurs intervenants (groupe / employés) sans les nommer individuellement. 

EndDefinition

Principe de fonctionnement

  • La liste des rôles est accessible via l'icône Roles-Tags window icon.png en regard des champs proposant l'utilisation de rôles (accés à une fenêtre d'aide à la saisie).
  • L'intervenant est recherché au moment de l'appel du rôle par le système, afin de retrouver sa valeur actuelle dans le contexte d'utilisation (identification des utilisateurs concernés via leur nom et adresse e-mail). La valeur du rôle (et donc des intervenants) peut ainsi être différente entre 2 appels, sans qu'il ait été nécessaire de le modifier.

Example documentation icon FR.png  Intervenant d'une action d'un workflow identifié lorsque celle-ci est déclenchée ; Destinataires d'un e-mail de notification identifiés lorsqu'une alerte est déclenchée

Classification des rôles

Rôles    "Par domaine"
  • Fonctions identifiant les intervenants dans les workflows hors CMDB, en tenant compte de leur domaine ou champ d'intervention (localisation/entité).
  • La liste des rôles est définie dans les tables de référence des menus Transition et Operation, en associant un groupe à un domaine. Note : Un groupe lié au domaine Toute la société peut intervenir sur tous les sites de la société.

Syntaxe : #[WF_ROLE.Nom du rôle par domaine]#

Example documentation icon FR.png#[WF_ROLE.Gestionnaire des changements]#

Roles - Domain list.png
Rôles    "Personnalisés"
  • Rôles créés par chaque client en fonction de ses besoins, lorsque ceux-ci ne correspondent à aucun rôle classifié dans l'une des autres catégories.
  • La liste des rôles est définie dans le menu Administration > Paramétrages > Rôles - Open url.png voir Description des écrans

Syntaxe : #[CUSTOM_ROLE.Nom du rôle personnalisé]#

Example documentation icon FR.png#[CUSTOM_ROLE.Propriétaire du matériel]#

Roles - Customized list.png
Rôles    "Système"
  • Fonctions prédéfinies dans Product name - ev itsm.png, associées à des intervenants bien précis.

Syntaxe : #[WF_ROLE.@Nom du rôle système]#

Example documentation icon FR.png#[WF_ROLE.@Responsable du CI]#

Roles - System list.png
Rôles    "CI"
  • Fonctions identifiant les intervenants dans les workflows de traitement des incidents/demandes impliquant des CI.
  • La liste des rôles est définie dans les tables de référence du menu Extended CMDB.

Syntaxe : #[WF_ROLE.Nom du rôle CI]#

Example documentation icon FR.png#[WF_ROLE.Responsable fonctionnel]#

Roles - CI list.png

Exemples

1. Rôles dans le workflow Processus téléphonie :

  • l'étape Analyse et résolution est réalisée par le rôle Maintenance téléphonie :
           --> inclure un rôle par domaine #[WF_ROLE.Téléphonie]# permettant d'identifier le groupe d'intervenants en fonction de la localisation du demandeur de l'incident
  • l'étape Validation utilisateur est réalisée par le rôle identifiant le demandeur de l'incident :
           --> inclure un rôle système #[CUSTOM_ROLE.Demandeur]#

2. Rôles par domaine : les incidents sont affectés au rôle Mainteneur et sont orientés vers un groupe différent en fonction de la localisation de l'utilisateur :

Rôle Domaine Groupe
Mainteneur

New York

Société 1

Boston

Société 2

Siège

Informatique interne

Remarques

  • Lorsque la requête SQL associée à un rôle personnalisé renvoie plusieurs valeurs, seule la première est prise en compte.

Best Practice big icon.pngBonnes pratiques

  • Utilisez la fenêtre d'aide à la saisie pour insérer les rôles, pour éviter tout risque d'erreurs de syntaxe.
  • Saisissez les rôles manuellement uniquement si vous faîtes un copier-coller d'un e-mail existant pour l'adapter à une autre situation.
  • Rôles personnalisés :
    • Pour réactiver un rôle personnalisé, effacez ou retardez sa date de fin au-delà de la date du jour.
    • Pour qu'un rôle personnalisé continue à fonctionner correctement là où il est déjà utilisé, mais pour interdire son utilisation sur de nouveaux éléments, archivez-le en appliquant une date de fin au lieu de le supprimer.
    • Dans la requête SQL d'un rôle personnalisé, pour que celui-ci fonctionne correctement dans les alertes renvoyant une liste d'enregistrements, utilisez toujours la syntaxe in(@ID@ et non =@ID@.

      Example documentation icon FR.png  Créer un rôle personnalisé Validateur financier du demandeur

      SELECT AM_VALIDATOR.employee_id
      FROM   sd_request
            INNER JOIN am_employee AM_REQUESTOR
                    ON AM_REQUESTOR.employee_id = sd_request.requestor_id
            INNER JOIN am_employee AM_VALIDATOR
                    ON AM_VALIDATOR.employee_id = AM_REQUESTOR.validator_id
      WHERE  sd_request.request_id IN ( @ID@ )  

Attention

  • Pour sélectionner un rôle dans la fenêtre d'aide à la saisie : cliquez sur le rôle souhaité puis fermez la fenêtre. Il n'y a pas de boutons de validation.
  • En cas d'erreur, supprimez manuellement l'instruction dans l'e-mail puis rouvrez la fenêtre d'aide à la saisie.

Description des écrans "Rôles personnalisés"

Accès menu : Administration > Paramétrages > Rôles personnalisés

Rôle personnalisé

         Role - step 1.png

Libellé : Libellé du rôle personnalisé. 

Date de fin : Date de fin de validité du rôle personnalisé, au-delà de laquelle celui ne peut plus être utilisé.

Contexte d'un rôle personnalisé

         Role - step 2.png

Nom de la table : Contexte d'utilisation du rôle personnalisé.

         Example documentation icon FR.png  Un rôle attaché à la table AM_ACTION peut être utilisé uniquement dans un workflow lié à cette même table

Type de données : Type de données retournées par la requête SQL :

  • Courriel : adresse e-mail ;
  • Employé : identifiant de l'utilisateur ;
  • Groupe : identifiant du groupe.

SQL : Requête SQL exécutée lorsque le rôle est sollicité et renvoyant une valeur qualifiée par le type de données.

  • La variable @ID@ identifie l'enregistrement courant.

Procédures et Assistants

Comment saisir les rôles dans un e-mail

1. Allez sur l'écran permettant la saisie d'un e-mail.

2. Saisissez les rôles :

Best Practice icon.png  Cliquez sur Roles-Tags window icon.png en regard d'un champ proposant l'utilisation de rôles.
         Roles - Workflow example.png
Dans la fenêtre d'aide à la saisie :

  • Cliquez sur l'onglet contenant le rôle à insérer -  Open url.png  voir Description des catégories
  • Cliquez sur le rôle souhaité.
  • Fermez la fenêtre : la syntaxe du rôle est automatiquement insérée.
  • Vous pouvez également saisir manuellement le rôle, en respectant la syntaxe relative à chaque catégorie.

3. Pour modifier ou supprimer un rôle inséré dans l'e-mail : effacez-le manuellement et éventuellement sélectionnez le nouveau comme à l'étape 2.

Comment créer un rôle personnalisé

1. Allez sur l'écran Administration > Paramétrages > Rôles personnalisés ; cliquez sur Add icon.png.

2. Saisissez le libellé du rôle et son éventuelle date de fin ; cliquez sur [ TERMINER ].

3. Cliquez sur l'onglet Contexte puis sur Add icon.png ; définissez les paramètres du rôle personnalisé et cliquez sur [ TERMINER ].

Les assistants

Modifier : Modifie le rôle personnalisé. 

Supprimer (Note : Uniquement pour un élément non utilisé dans l'application) : Supprime le rôle personnalisé.

 

Liste des rôles système

Rôle Fonction Remarques Champ/Tag correspondants
@Bénéficiaire Bénéficiaire de l’incident/demande
  • Renseignez ce rôle lorsque le bénéficiaire est différent du demandeur.
  • Rôle généralement utilisé avec les types d'action Envoi de mail (notifier que la demande a bien été prise en compte), Validation Self-service (demander l'évaluation/validation de la qualité/rapidité de l'intervention - avec ou sans rating), Évaluation (demander l'évaluation de la qualité/rapidité de l'intervention).
  • Champ AM_RECIPIENT.LAST_NAME sur la fiche Incident/Demande
  • Référence dans un e-mail : tag #RECIPIENT#
@Bénéficiaire et groupe par défaut Bénéficiaire de l'incident/demande et Groupe d'appartenance par défaut
  • Les 2 rôles sont utilisés conjointement lorsqu'une action est affectée au bénéficiaire.
  • Si le bénéficiaire ne fait partie d’aucun groupe, le champ Groupe reste vide dans l’historique des actions.
  • Rôle faisant référence à plusieurs champs : aucun tag associé
@Demandeur Personne signalant l’incident/demande
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir que la demande a bien été prise en compte), Validation Self-service (demander l'évaluation/validation de la qualité/rapidité de l'intervention - avec ou sans rating), Évaluation (demander l'évaluation de la qualité/rapidité de l'intervention).
  • Champ AM_REQUESTOR.LAST_NAME sur la fiche Incident/Demande
  • Référence dans un e-mail : tag #REQUESTOR#
@Demandeur et groupe par défaut Demandeur de l'incident/demande et Groupe d'appartenance par défaut
  • Les 2 rôles sont utilisés conjointement lorsqu'une action est affectée au demandeur.
  • Si le demandeur ne fait partie d’aucun groupe, le champ Groupe reste vide dans l’historique des actions.
  • Rôle faisant référence à plusieurs champs : aucun tag associé
@Groupe clôturant Groupe intervenu sur l’action clôturante ayant permis à l'incident/demande de prendre un méta-statut Terminé
  • Le groupe clôturant apparaît sur la liste des actions.
  • Toute action utilisant ce rôle doit être placée après l’action clôturante pour que le groupe clôturant soit identifié.
  • Champ LAST_GROUP_ID de la table SD_REQUEST
  • Référence dans un e-mail : tag #CLOSING_GROUP#
@Groupe responsable de la mise en production Groupe associé au projet de mise en production
  • Champ AM_GROUP.GROUP_$lng sur la fiche Projet de mise en production
  • Référence dans un e-mail : tag #RELEASE_GROUP_MANAGER#
@Groupe responsable de l’incident/demande Groupe auquel appartient la personne ayant saisi l'incident/demande
  • Si l'intervenant appartient à plusieurs groupes, le groupe responsable est sélectionné de manière aléatoire parmi tous ses groupes.
  • Les incidents affectés aux groupes de l'intervenant sont visibles via le menu Incidents > Incidents de mes groupes.
  • Champ AM_GROUP.GROUP_$lng sur la fiche Incident/Demande
  • Référence dans un e-mail : tags #OWNING_GROUP# ou #GROUP_MANAGER#. Note : Ces tags renvoient une valeur identique uniquement lorsque l’intervenant appartient à un seul groupe.
@Groupe responsable du catalogue Groupe responsable de l'incident/demande via les sujets définis au niveau des catalogues
  • Champ AM_GROUP.GROUP_$lng sur le catalogue Incident/Service
  • Référence dans un e-mail : tag #CATALOG_GROUP# ou #GROUP_MANAGER#
@Incident enregistré par Personne ayant saisi l'incident/demande
  • Rôle généralement utilisé avec le type d'action Envoi de mail (conserver une trace de la saisie sous forme de notification).
  • Champ AM_SUBMITTED_BY.LAST_NAME sur la fiche Incident/Demande
  • Référence dans un e-mail : tag #SUBMITTED_BY#
@Intervenant clôturant Personne intervenue sur l’action clôturante ayant permis à l'incident/demande de prendre un méta-statut Terminé
  • L'intervenant clôturant apparaît sur la liste des actions.
  • Toute action utilisant ce rôle doit être placée après l’action clôturante pour que l’intervenant clôturant soit identifié.
  • Champ LAST_DONE_BY_ID de la table SD_REQUEST
  • Référence dans un e-mail : champ de la base de données #[DB_FIELDS.LAST_DONE_BY_ID.AM_EMPLOYEE.LAST_NAME]#
@Propriétaire du matériel Utilisateur principal auquel est affecté le matériel
  • Le code matériel sur l'incident/demande doit être renseigné.
  • Champ AM_EMPLOYEE.LAST_NAME sur la fiche Matériel
  • Référence dans un e-mail : champ de la base de données #[DB_FIELDS.OWNER_ID.AM_EMPLOYEE.LAST_NAME]#
@Responsable de la localisation du bénéficiaire Responsable de la localisation à laquelle est rattaché le bénéficiaire de l'incident/demande
  • Toutes les localisations de niveau inférieur à celle pour laquelle un responsable est défini héritent du responsable.
  • Champ TMP_AM_MANAGER.LAST_NAME sur la fiche Localisation
  • Référence dans un e-mail : tag #RECIPIENT_LOCATION_MANAGER#
@Responsable de la localisation du demandeur Responsable de la localisation à laquelle est rattaché le demandeur de l'incident/demande
  • Toutes les localisations de niveau inférieur à celle pour laquelle un responsable est défini héritent du responsable.
  • Champ TMP_AM_MANAGER.LAST_NAME sur la fiche Localisation
  • Référence dans un e-mail : tag #REQUESTOR_LOCATION_MANAGER#
@Responsable de la mise en production Intervenant associé au projet de mise en production
  • Champ AM_EMPLOYEE.LAST_NAME sur la fiche Projet de mise en production
  • Référence dans un e-mail : tag #RELEASE_MANAGER#
@Responsable de l'entité du bénéficiaire Responsable de l'entité à laquelle est rattaché le bénéficiaire de l'incident/demande
  • Toutes les entités de niveau inférieur à celle pour laquelle un responsable est défini héritent du responsable.
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le responsable qu'un de ses membres a émis une demande), Validation Self-service (obtenir l'agrément du responsable suite à une demande émise par l'un des membres).
  • Champ TMP_AM_MANAGER.LAST_NAME sur la fiche Entité
  • Référence dans un e-mail : tag #RECIPIENT_DEPARTMENT_MANAGER#
@Responsable de l'entité du demandeur Responsable de l'entité à laquelle est rattaché le demandeur de l'incident/demande
  • Toutes les entités de niveau inférieur à celle pour laquelle un responsable est défini héritent du responsable.
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le responsable qu'un de ses membres a émis une demande), Validation Self-service (obtenir l'agrément du responsable suite à une demande émise par l'un des membres).
  • Champ TMP_AM_MANAGER.LAST_NAME sur la fiche Entité
  • Référence dans un e-mail : tag #REQUESTOR_DEPARTMENT_MANAGER#
@Responsable de l’incident Responsable de l'incident/demande
  • Par défaut, il s'agit de la personne ayant saisi l'incident/demande.
  • Les incidents affectés au responsable sont visibles via le menu Incidents > Mes incidents.
  • Champ AM_OWNER.LAST_NAME sur la fiche Incident
  • Référence dans un e-mail : tag #OWNER#
@Responsable du bénéficiaire Supérieur hiérarchique direct du bénéficiaire de l'incident/demande
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le responsable qu'un de ses membres a émis une demande), Validation Self-service (obtenir l'agrément du responsable suite à une demande émise par l'un des membres).
  • Champ V_MANAGER.LAST_NAME sur la fiche Incident/Demande
  • Référence dans un e-mail : tag #RECIPIENT_MANAGER#
@Responsable du catalogue Responsable de l'incident/demande via les sujets définis au niveau des catalogues
  • Rôle généralement utilisé avec les types d'action Envoi de mail (notifier le responsable qu'un nouvel incident/demande le concerne), Traitement Opération/Transition (générer une action pour le responsable en charge du sujet), Validation Self-service/Opération/Transition (obtenir l'agrément du responsable lors d'une étape de validation).
  • Champ AM_MANAGER.LAST_NAME sur le catalogue Incident/Service
  • Référence dans un e-mail : tag #MANAGER# ou #CATALOG_MANAGER#
@Responsable du CI Responsable du CI impliqué dans l'incident/demande
  • Champ AM_EMPLOYEE.LAST_NAME sur la fiche CI
  • Référence dans un e-mail : tag #CI_MANAGER#
@Responsable du demandeur Supérieur hiérarchique direct du demandeur de l'incident/demande
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le responsable qu'un de ses membres a émis une demande), Validation Self-service (obtenir l'agrément du responsable suite à une demande émise par l'un des membres).
  • Champ V_MANAGER.LAST_NAME sur la fiche Incident/Demande
  • Référence dans un e-mail : tag #REQUESTOR_MANAGER#
@Responsable du groupe responsable du catalogue Responsable du groupe responsable de l’incident/demande
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le validateur financier), Traitement Opération/Transition, Validation Opération/Transition (obtenir l'agrément du responsable pour un incident/demande le concernant).
  • Champ AM_MANAGER.LAST_NAME sur la fiche Groupe
  • Référence dans un e-mail : tag #CATALOG_GROUP_MANAGER#
@Validateur financier Validateur financier direct du demandeur de l'incident/demande
  • Rôle généralement utilisé avec les types d'action Envoi de mail (prévenir le validateur financier), Validation Self-service (obtenir l'agrément du responsable pour un incident/demande le concernant)
  • Champ V_VALIDATOR.LAST_NAME sur la fiche Employé
  • Référence dans un e-mail : tag #FINANCIAL_VALIDATOR#
Tags:
Modifié par Utilisateur inconnu le 2019/05/20 17:53
Créé par Administrator XWiki le 2013/03/25 18:11

Raccourcis

L'actualité mensuelle
•  Newsletter

Tous les changements
•  Service Engine
•  Service Apps
•  Self Help

Glossaire

Powered by XWiki ©, EasyVista 2019