Escalader aux utilisateurs n’ayant pas terminé leur tâche

Aujourd’hui une petite astuce simple et forcément méconnue. Il vous est surement arrivé d’assigner une tâche à plusieurs personnes et de positionner une escalade en cas de non traitement de la tâche dans un délai imparti. Dans la majorité des cas la configuration réalisée permet l’envoi du mail d’alerte, mais à tous les utilisateurs qui ont reçu originellement la tâche (i.e. sous entendu même ceux ayant déjà fait leur travail), nous allons donc voir dans ce billet comment faire en sorte que seuls les utilisateurs n’ayant pas encore traité leur travail reçoivent cette alerte.

En une phrase, il suffit simplement de paramétrer l’escalade au niveau de l’event client et non pas au niveau de l’activity. En effet, la plupart du temps les concepteurs vont configurer leur alerte depuis cette interface :

Accès au paramétrage d'une alerte au niveau d'une activité
Accès au paramétrage d’une alerte au niveau d’une activité

Cependant, il est possible de configurer un autre type d’alertes au niveau de l’événement client, en faisant un clic-droit > Properties sur l’événement concerné (un double-clic sur l’icône de l’événement fonctionne aussi ) :

Accès au paramétrage d'une alerte au niveau d'un événement
Accès au paramétrage d’une alerte au niveau d’un événement

Une fois que l’assistant de l’événement est affiché, vous pouvez cliquer sur l’icône “horloge” pour ajouter une escalade. Vous noterez qu’ici, seule l’action email est disponible (contrairement aux escalades d’activité où il est aussi possible de paramétrer des réassignations, des expirations…). Puis lors de la configuration du mail, il sera nécessaire de positionner le champ Workflow Context > Activity Destination Instance > User > Email comme destinataire du mail :

Configuration du destinataire de l'alerte
Configuration du destinataire de l’alerte

 

Ensuite, il reste simplement à vous assurer que la destination rule est configurée pour s’exécuter en Plan per destination, que si des groupes/rôles sont utilisés, il y a bien une résolution faite à l’utilisateur et évidemment qu’il y a plusieurs Slots créés (sinon, cela n’aurait pas de sens) :

Configuration de Slots nécessaire
Configuration de Slots nécessaire

Quelques remarques

  • Utiliser ceci nécessite donc de passer par de la planification par destination, comme cela a été expliqué dans le billet suivant, cela peut avoir un impact sur les événements systèmes utilisés au sein de la même activité et donc, cela peut jouer sur les performances. Il est donc important de faire cette configuration en connaissance de cause (quitte à exécuter les événements systèmes au sein d’une autre activité).
  • Profitons de ce billet pour indiquer qu’il est également nécessaire de passer par cette configuration au niveau de l’événement client afin d’accéder à la gestion des escalades basée sur les heures de travail de l’utilisateur concerné par le slot (mode avancé de ma configuration), ce qui permet d’envoyer l’alerte sur les heures de travail de chacun des utilisateurs (et donc potentiellement à des moments différents) :

    Utiliser les heures de travail configurées au niveau d'un utilisateur
    Utiliser les heures de travail configurées au niveau d’un utilisateur

Happy K2ing!

jean

Directeur technique de K2 France depuis 2006 et passionné par les technologies, je travaille dans le monde du BPM et des applications métier depuis… que je travaille :). Vous pouvez également me suivre sur twitter, linkedin.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *