Le workflow de validation que chaque équipe possède
Quelque chose est demandé, quelqu'un en fait la review, des modifications sont apportées, et à un moment donné, le tout est validé. Tasked en fait un type d'étape, et non un statut. Lorsqu'un élément entre dans une étape de validation, le moteur ouvre une validation à son sujet. L'élément ne peut pas en sortir via la transition validée tant qu'une décision n'a pas été enregistrée, et la personne qui décide peut le faire via un accès sans avoir besoin de compte. Ce même objet peut être une signature de script, un cut final, une review de marque, une livraison ou un client qui vérifie un correctif.
Une étape, pas un statut
Lorsqu'un élément entre dans une étape de validation, le moteur ouvre une validation pour celui-ci. L'élément ne peut pas en sortir via la transition validée tant qu'une décision n'est pas enregistrée. Un rejet ou une demande de modifications renvoie l'élément vers l'étape de correction définie par le workflow.
Le pack de workflow de validation prend cette forme : demandé (travail, 24 heures), en review (validation, 48 heures), modifications demandées (travail, 48 heures), validé (travail, 24 heures), terminé. L'étape en review est le point de passage. L'étape modifications demandées renvoie à l'étape en review une fois la checklist complétée.
- La validation s'ouvre à l'entrée, la sortie est refusée sans décision
- Une étape de correction définie pour les modifications demandées
- L'objet de validation ne contient aucune référence à un type de fichier
Où les packs placent le point de passage
La publicité et la vidéo d'entreprise placent la validation du script avant le tournage et la validation du cut final avant la livraison. Le documentaire impose la validation du traitement et la validation du cut final. Le film de mariage prévoit une seule validation du cut final après le film complet. Le lot de contenus pour les réseaux sociaux intègre une validation du plan et une étape de publication. La demande de design place la review client après la review interne. La campagne propose une review de marque et une review juridique. Le logiciel et le déploiement demandent une validation de déploiement. L'incident requiert une vérification client. Dans tous les cas, le moteur utilise le même objet.
Qui peut décider, et l'historique
Chaque étape désigne les rôles qui en sont responsables. Un approbateur externe à l'espace de travail reçoit un accès : un code, un lien, un numéro de téléphone ou une adresse e-mail. Grâce à cet accès, il peut voir l'élément, ajouter des notes et cliquer sur valider, rejeter ou demander des modifications. La décision est enregistrée avec l'identité de l'accès, l'heure, et l'information indiquant si elle a été prise par un membre ou via le portail.
Chaque décision est inscrite dans un journal d'audit en écriture seule. Rien ne peut y être modifié ou supprimé depuis l'application. L'exportation de données l'inclut également. Des webhooks se déclenchent lors des décisions avec un journal de transmission. Des rappels sont envoyés avant l'expiration du délai. Une validation laissée en attente pendant plusieurs jours constitue un motif explicite dans le score de risque du projet.
Questions fréquentes
- Un élément peut-il nécessiter deux validations ?
- Oui. Deux étapes de validation successives, chacune ayant son propre responsable, son délai et son parcours de correction. Le pack de campagne est configuré ainsi, avec une review de marque et une review juridique.
- Que se passe-t-il si l'approbateur n'est pas un utilisateur de l'espace de travail ?
- Il reçoit un accès et prend sa décision par ce biais. Sans compte, sans place.
- Une décision peut-elle être modifiée ultérieurement ?
- Une nouvelle décision peut être enregistrée ; la précédente reste dans le journal d'audit en écriture seule. Rien n'est écrasé.
- Est-ce réservé à la vidéo ?
- Non. L'objet de validation est un point de passage sur une tâche et une étape. Il fonctionne de la même manière pour un script, un design, un déploiement ou un incident.