Votre espace peut décider que certaines créations ou modifications de fiches du CRM, et certains envois vers des clients ou des membres, passent par une validation humaine avant d’être définitifs. Tant qu’une personne n’a pas décidé, rien n’est écrit ni envoyé. Cet article explique comment régler ce qui est soumis, qui décide, comment valider ou refuser une demande, et ce que vit le demandeur pendant l’attente. Il s’adresse aux administrateurs du CRM, aux valideurs et aux commerciaux.
Avant de commencer #
- Le module CRM doit être activé pour votre espace (voir Activer et administrer le module CRM).
- Les réglages : « Réglages du CRM : consulter » pour ouvrir Paramètres › CRM › Validations, « Réglages du CRM : modifier » pour les enregistrer.
- Les demandes, droit « Validations : consulter » (matrice des rôles, menu CRM) : il donne l’entrée CRM › Validations et montre les demandes des personnes de votre portée, en plus des vôtres.
- La décision, droit « Validations : valider ou refuser » : il permet de décider les demandes des personnes de votre portée, jamais les vôtres.
- La portée vise le demandeur. Elle se règle par rôle dans la carte Portées CRM, domaine Validations, opérations Lire et Décider (voir Les réglages du CRM). Par défaut, seul le rôle Administrateur détient ces deux droits, avec la portée Tous.
- Armer un circuit dans Workflows demande les droits des workflows (voir Créer et modifier un workflow).
- Demander ne demande aucun droit particulier : chaque geste garde ses droits habituels.
Par défaut, rien n’est soumis #
Tant que personne n’a rien coché dans Paramètres › CRM › Validations, le CRM écrit et envoie comme d’habitude. Les réglages disent ce qui attend une décision. Le circuit de Workflows dit qui décide.
Régler ce qui est soumis #
- Ouvrez Paramètres › CRM › Validations.
- Pour chaque objet, Compte, Contact, Opportunité ou dossier et Adhésion, cochez au besoin Création soumise à validation.
- Sous Modification soumise pour ces champs, cochez les champs dont le changement doit attendre une décision.
- Sous Pour ces origines (aucune cochée : toutes), cochez les origines visées par la règle de cet objet.
- Dans Envois vers un tiers, cochez les envois à faire valider.
- Cliquez sur Enregistrer.
Appliquer le préréglage remplit le formulaire avec une proposition : la création des quatre objets soumise pour les origines IA, API et Formulaire public, la modification des identifiants légaux d’un compte, et l’envoi d’un appel de cotisation. Rien n’est enregistré avant Enregistrer.
Les champs qui peuvent être soumis #
| Objet | Champs |
|---|---|
| Compte | Raison sociale, Identifiants légaux, Adresses, Propriétaire, Secteur, Notes, Étiquettes, Champs personnalisés |
| Contact | Prénom, Nom, E-mails, Téléphones, Fonction, Propriétaire, Notes, Champs personnalisés |
| Opportunité ou dossier | Nom, Montant, Devise, Date de signature prévue, Propriétaire, Champs personnalisés |
| Adhésion | Catégorie, Contact référent, Propriétaire, Note |
Les origines #
| Origine | Ce qu’elle couvre |
|---|---|
| Saisie à l’écran | Ce que vous créez ou modifiez dans les écrans du CRM. |
| Import | Chaque ligne d’un import de fichier ou d’un autre CRM, et le réimport d’un export complet. |
| API | Une écriture faite avec un jeton API, par exemple depuis un outil d’automatisation. |
| IA | Les fiches créées par Créer les fiches depuis un e-mail préparé par l’IA. |
| E-mail relevé | Les mêmes fiches préparées par l’IA, puisqu’elles viennent toujours d’un e-mail de la file : une règle qui vise cette origine les soumet aussi. |
| Formulaire public | Aucune écriture du CRM ne porte aujourd’hui cette origine : la cocher seule ne soumet rien. |
Les envois vers un tiers #
Trois envois peuvent être soumis : Envoi d’un devis, Envoi d’un appel de cotisation et Invitations à un événement. Un envoi soumis ne part qu’après la décision, y compris par l’API, et quel que soit le mode choisi : par e-mail ou remis autrement. La réponse rédigée par l’IA n’est pas dans cette liste : elle ne part jamais d’Illizeo (voir L’intelligence artificielle dans le CRM).
Ce qui se passe quand un geste est soumis #
- Une création n’écrit rien : la fiche n’existe pas encore. Elle n’apparaît dans aucune liste, aucun rapport, aucun webhook. Tant qu’elle attend, une seconde création de la même fiche est refusée, qu’elle soit soumise ou non : même raison sociale ou même organisation pour un compte, même adresse e-mail pour un contact, même club et même membre pour une adhésion.
- Une modification attend tout entière dès que l’un des champs soumis change, pas seulement ce champ : la fiche garde ses anciennes valeurs jusqu’à la décision. Un champ renvoyé à l’identique ne soumet rien. Les étiquettes et les champs personnalisés font exception : dès qu’une modification les contient, elle est soumise, même s’ils n’ont pas changé.
- Un passage d’étape qui change le montant, la devise ou la date de signature d’une opportunité attend comme une modification : l’affaire reste à son étape. Validé, le passage est refait en entier.
- Une réaffectation de plusieurs comptes, quand le propriétaire est soumis, pose une demande par compte. Rien n’est réaffecté avant les décisions.
- Un envoi ne part pas. Le devis, l’appel de cotisation ou les invitations restent dans leur état.
- Un import pose une demande par ligne soumise. Ces lignes sont comptées « En attente de validation » dans le compte rendu de l’import. Une simulation les compte sans poser de demande.
- Une écriture par l’API reçoit une réponse 202 avec l’identifiant de la demande. L’intégration lit ensuite l’état de la demande par l’API, avec un jeton qui porte la ressource « CRM — demandes de validation » (voir Importer, exporter et utiliser l’API).
Qui décide : le circuit #
Chaque demande démarre un circuit du moteur de workflows, selon son déclencheur : « Création d’une fiche à valider », « Modification d’une fiche à valider » ou « Envoi vers un tiers à valider ».
- Sans workflow actif pour ce déclencheur, la demande suit le circuit de repli : le supérieur hiérarchique du demandeur décide. Ce circuit apparaît dans Workflows à la première demande, sous le nom « Circuit de repli — supérieur hiérarchique ».
- Trois circuits sont livrés inactifs, dans la catégorie CRM de Paramètres › Gérer les employés › Workflows : « Création par l’IA : validation », « Identifiant légal modifié : validation » et « Envoi d’un appel de cotisation : validation ». Chacun envoie la demande au responsable du demandeur quand sa condition est remplie : origine IA, champ Identifiants légaux, ou type d’envoi appel de cotisation.
- Un workflow actif prend toutes les demandes de son déclencheur. Celles qu’il termine sans étape d’approbation, par exemple une création venue de l’API quand seul « Création par l’IA : validation » est actif, attendent un valideur du CRM : tous les détenteurs de « Validations : valider ou refuser » dont la portée couvre le demandeur sont prévenus.
- Seule une décision humaine compte, et jamais celle du demandeur lui-même.
- À tout moment, un détenteur de « Validations : valider ou refuser » dans sa portée peut décider depuis le CRM. Le circuit encore ouvert est alors annulé.
Armer un circuit ne soumet rien par lui-même : sans la case correspondante dans Paramètres › CRM › Validations, aucune demande ne lui parvient.
Le valideur désigné reçoit une notification et un e-mail. S’il peut décider dans le CRM (« Validations : valider ou refuser », dans une portée qui couvre le demandeur), ils mènent à la demande dans le CRM. Sinon, ils mènent à Flux de travail, onglet Approbations (voir Approuver, refuser ou déléguer une demande).
Consulter et décider les demandes #
Ouvrez CRM › Validations. La liste montre vos demandes et celles des personnes de votre portée, les plus récentes en tête. Filtrez-la par Statut et par Objet. Chaque ligne donne la Demande (son libellé, le geste et la date), l’Objet, l’Origine, le Demandeur et le Statut.
| Statut | Signification |
|---|---|
| En attente | Personne n’a encore décidé. Rien n’est écrit ni envoyé. |
| Validée | Le geste du demandeur a été rejoué et appliqué. |
| Refusée | Rien n’a été écrit ni envoyé. Le motif est sur la demande. |
| Validée, non appliquée | La demande a été validée, mais le geste n’a pas pu être rejoué : rien n’a été écrit. La raison est sur la demande. |
Cliquez sur une demande pour l’ouvrir. Elle indique le geste et l’objet, l’Origine, le Demandeur, la date de la demande et, une fois tranchée, la date de la décision et son auteur. Une création montre Ce qui sera créé, champ par champ ; une modification, Avant / après. Une demande d’envoi ou de fiches préparées par l’IA n’a pas de tableau : son titre donne le numéro du devis ou de l’appel, le titre de l’événement, ou le nom de l’organisation proposée.
- Cliquez sur Valider ou sur Refuser. Ces boutons n’apparaissent que si vous pouvez décider cette demande.
- Pour valider, ajoutez au besoin un Commentaire. Pour refuser, saisissez le Motif (obligatoire) : le demandeur le recevra.
- Confirmez avec Valider ou Refuser.
Validée, la demande rejoue le geste du demandeur, à son nom, avec ses droits du jour et sur l’état présent du CRM. Si le geste n’est plus possible, par exemple parce qu’un droit lui a été retiré ou qu’un doublon est apparu entre-temps, la demande passe en Validée, non appliquée et rien n’est écrit. Une fois validée, le lien Ouvrir la fiche mène à la fiche créée ou modifiée. Une demande déjà tranchée ne se décide pas deux fois : « Cette demande a déjà été tranchée. »
Côté demandeur : pendant l’attente #
- Quand votre geste est soumis, le message « Envoyé en validation : rien n’est écrit tant qu’une personne n’a pas validé. » s’affiche, avec Voir la demande. C’est le cas à la création ou à la modification d’un compte, d’un contact, d’une opportunité ou d’une adhésion, à l’envoi d’un devis ou d’un appel de cotisation, aux invitations à un événement et à la création des fiches préparées par l’IA.
- Un envoi groupé d’appels de cotisation dit combien d’envois attendent : « … envoi(s) en attente de validation : ils partiront après la décision. », avec Voir les demandes.
- Si la même fiche attend déjà une validation, le message le dit : « La même fiche attend déjà une validation : rien n’est écrit tant qu’une personne n’a pas décidé. »
- Un passage d’étape ou une réaffectation de comptes soumis s’affiche comme un échec, avec le message « Cette modification attend une validation : rien n’est écrit tant qu’une personne ne l’a pas approuvée. » (« Ces modifications attendent… » pour plusieurs comptes), sans lien vers la demande. La demande est pourtant bien posée.
- La fiche ne montre rien de l’attente : une fiche à créer n’existe pas encore, une fiche modifiée garde ses anciennes valeurs. Pour des fiches préparées par l’IA, l’e-mail de la file affiche « Fiches en attente de validation ».
- Vous suivez vos demandes dans CRM › Validations. Sans le droit « Validations : consulter », l’entrée n’est pas dans le menu : vos demandes s’ouvrent par le lien du message ou de la notification.
- Vous ne pouvez pas retirer une demande vous-même. Pour l’abandonner, demandez au valideur de la refuser.
La décision #
Vous recevez une notification et un e-mail : « CRM : modification validée », « CRM : modification refusée », avec le motif, ou « CRM : modification validée mais non appliquée ». Un clic ouvre la demande. Après un refus ou un échec, rien n’a été écrit : ressaisissez le geste si besoin. Des fiches préparées par l’IA reviennent à revoir : vous les corrigez et les soumettez de nouveau, ou vous les écartez.
Notifications, e-mails et journal #
- Les notifications et les e-mails de ces demandes se coupent dans Paramètres personnels › Notifications, ligne « CRM — validations : demandes à décider, demandes validées ou refusées » (voir Choisir ses notifications).
- Les textes des quatre e-mails se personnalisent dans Paramètres › Gérer Illizeo › Email, catégorie CRM : « CRM — une modification à valider (au valideur que le circuit désigne) », « CRM — modification validée (au demandeur) », « CRM — modification refusée (au demandeur, avec le motif) » et « CRM — modification validée mais non appliquée (au demandeur) ». Aucun ne reprend les valeurs saisies : la demande se lit à l’écran.
- Le journal du CRM garde chaque demande, chaque décision avec son auteur et l’avant / après, et chaque changement des réglages des validations.
À savoir #
- Les droits du demandeur sont relus au moment de la décision : une demande validée après le retrait de son droit échoue sans rien écrire.
- L’effacement d’un contact au titre de la protection des données efface aussi les demandes de validation de sa fiche, quel que soit leur état.
- Modifier les réglages ne change pas les demandes déjà posées : elles attendent leur décision.
Questions fréquentes #
Qui est prévenu quand une demande est posée ? #
Le valideur que le circuit désigne : le supérieur hiérarchique du demandeur tant qu’aucun workflow n’est actif, ou l’approbateur du workflow actif. Quand un workflow termine la demande sans étape d’approbation, ce sont les détenteurs de « Validations : valider ou refuser » dont la portée couvre le demandeur. S’il n’y en a aucun, la demande attend sans que personne ne soit prévenu.
Le valideur ouvre la demande mais ne voit ni Valider ni Refuser. #
Il lui manque « Validations : valider ou refuser » dans une portée qui couvre le demandeur, ou c’est sa propre demande. S’il est le valideur désigné par le circuit, il décide dans Flux de travail, onglet Approbations, là où mène son avis, même sans droit dans le CRM : sa décision s’applique comme une décision prise dans le CRM.
