Actions planifiées

Les agents REDA AI peuvent préparer des actions différées, comme envoyer un e-mail, créer un enregistrement Salesforce ou notifier une équipe. Le parcours crée un enregistrement Action planifiée de l'IA, traité ensuite selon une date ou une réponse par e-mail. La validation par l’utilisateur dépend du parcours et des instructions : ne supposez pas une confirmation obligatoire universelle. Ce guide explique comment consulter les actions, leurs conditions et leur résultat.

Qu’est-ce qu’une action planifiée ?

Une action planifiée décrit une opération à effectuer ultérieurement. Les mécanismes fournis sont une échéance temporelle et la réception d’une réponse par e-mail dans un parcours configuré. Le succès de la planification ne garantit pas celui de l’opération future : les données, conditions, autorisations et traitements doivent encore permettre son exécution.

Exemples d’utilisation

• À heure fixe : « Créez une tâche de rappel demain à 9 h. »
• À heure fixe : « Envoyez un e-mail de suivi au client dans 3 jours. »
• À heure fixe : « Préparez une demande de réunion pour lundi prochain à 14 h. » Vérifiez l’action et les paramètres pris en charge pour ce résultat.
• À la réception d’un e-mail : « Prévenez l’équipe commerciale lorsqu’une réponse du client est reçue. » Cela nécessite le suivi des e-mails et un rapprochement correctement configurés.
• À échéance, avec condition : « Créez une tâche de suivi dans 14 jours si l’opportunité n’est pas passée à Closed Won. » Il s’agit d’un contrôle de champ à la date prévue, pas d’un abonnement générique à tous les événements Salesforce.

Création d’une action

Lorsqu’une demande doit être différée, un agent disposant de l’outil schedule_action peut créer l’action :

1. L’utilisateur exprime le besoin — Par exemple : « Rappelez-moi de relancer John dans 2 heures. »
2. L’agent prépare les paramètres — Il détermine l’action, la date et les informations nécessaires, puis appelle schedule_action dans le parcours autorisé.
3. L’action est enregistrée — Le type, les paramètres JSON, l’échéance et les éventuelles conditions sont conservés sur l’enregistrement.
4. L’agent présente le résultat — Il peut confirmer « Le rappel est planifié dans 2 heures ». Vérifiez que l’outil a réellement réussi et que l’enregistrement porte les bonnes valeurs.
5. Le traitement intervient plus tard — Une action temporelle est prise par le traitement des échéances ; une action sur réponse e-mail dépend du traitement asynchrone de l’e-mail reçu.

Types de déclencheur

Deux mécanismes sont prévus :

Déclenchement temporel

L’action devient admissible à partir de la date et heure enregistrées. Le traitement est prévu toutes les 15 minutes, sous réserve de sa planification et de son exécution Salesforce. Précisez le fuseau de la demande et vérifiez l’instant enregistré : une date sans indication de fuseau ne signifie pas automatiquement UTC.

• Date future : le parcours exige une date future valide. Le repère de 30 jours n’est pas un plafond universel vérifié dans cette validation. Une date absolue telle que 2026-03-15T14:00:00 ne contient pas de fuseau ; précisez l’instant attendu. Des demandes relatives comme +2h, +1d ou +1w doivent être converties en date par l’agent avant l’appel : ces abréviations ne sont pas des valeurs littérales acceptées par le parseur de date du parcours décrit.
• Fenêtre d’exécution : une action prévue à 14 h peut devenir admissible au passage suivant, vers 14 h 15 dans un fonctionnement nominal. Les files Salesforce, erreurs ou retards peuvent repousser l’exécution ; ce n’est pas une garantie d’achèvement dans les 15 minutes.
• Exemple : une échéance explicitement définie au 15 mars 2026 à 14 h UTC devient admissible à cet instant. Vérifiez l’affichage dans votre fuseau et le résultat effectif du traitement.

Déclenchement sur réponse e-mail

Le traitement des e-mails reçus peut rechercher les actions en attente de type Réponse par courriel. Il nécessite la configuration de réception Salesforce, l’activation du suivi et l’appel du gestionnaire depuis le flux approprié :

• Rapprochement des e-mails : le traitement utilise le fil associé à l’e-mail suivi et un rapprochement de l’objet normalisé. Ce n’est pas une surveillance générique d’une adresse expéditrice.
• Traitement après réception : un travail asynchrone est mis en file. Il ne dépend pas du passage temporel de 15 minutes, mais n’est pas une exécution synchrone ou instantanée garantie.
• Exemple : une réponse concernant la requête X peut correspondre à une action suivie. L’adresse customer@example.com seule ne constitue pas le critère de rapprochement ; vérifiez le fil et l’objet pour éviter une correspondance non souhaitée.
• Analyse IA facultative : si Traitement par IA est activé, le contenu de la réponse est analysé à l’aide de l’Invite d'analyse IA renseignée ou du prompt par défaut. L’analyse peut décider d’exécuter ou d’omettre l’action et consomme des crédits selon le parcours.

Champs de l’action

Accéder aux actions

Depuis la liste des actions

1. Ouvrez l’application REDA AI — Dans le lanceur d’application, sélectionnez REDA AI.
2. Examinez la navigation — Selon la largeur et la configuration, les onglets supplémentaires peuvent être regroupés dans le menu de débordement.
3. Ouvrez Actions planifiées par l'IA — La vue présente les actions accessibles. Vérifiez son tri et ses filtres ; elle n’affiche pas nécessairement toutes les actions de l’organisation.
4. Examinez les colonnes — Conversation, Statut, Exécuter à, Type d'action et Message d'erreur sont utiles selon la vue configurée.
5. Ouvrez une action — Vérifiez ses paramètres, conditions, état, compteur et résultat conservé. Un enregistrement n’est pas un historique détaillé de toutes les tentatives précédentes.

Depuis une conversation

La liste liée des actions planifiées, si elle figure sur la page, présente les actions associées à la conversation. Ouvrez l’une d’elles pour en examiner les détails.

Comprendre les statuts

Exécution conditionnelle

Une condition est évaluée au moment du traitement. Elle peut empêcher une action si la situation a changé, par exemple « envoyer le suivi uniquement si le champ indiquant la réponse reste vide » ou « agir uniquement si le critère de clôture n’est pas atteint ». Une condition non satisfaite conduit à Omission avec une raison ; elle ne vérifie que le champ configuré, pas une intention métier implicite.

Construire une condition

La condition compare un seul champ de l’enregistrement de contexte. Ce n’est ni une requête libre ni une formule complète :

L’action doit aussi désigner un enregistrement de contexte et son objet. Une condition portant sur un champ sans ce contexte est inexploitable : l’action n’est pas exécutée sans contrôle.

Comparaisons disponibles

Ces valeurs sont des identifiants techniques à ne pas traduire. Le parcours normalise la casse et les espaces de l’opérateur, mais rejette les opérateurs non pris en charge. Utilisez les formes canoniques suivantes :

Exemple détaillé

Un agent prévoit un suivi dans deux jours si l’opportunité n’a pas atteint la valeur Closed Won. Il renseigne l’opportunité comme contexte, puis :

• Champ de condition : StageName
• Opérateur de condition : not_equals
• Valeur de condition : Closed Won

Deux jours plus tard, le traitement relit StageName. Si sa valeur diffère de Closed Won, la condition est satisfaite et l’opération peut être tentée. Si elle lui est égale, l’action passe à Omission. Ce test ne signifie pas « aucune clôture » : une autre étape, notamment Closed Lost, peut aussi être différente de Closed Won et donc satisfaire la condition. Choisissez le champ et la valeur qui représentent réellement votre règle.

Condition impossible à vérifier

Une condition configurée n’est pas ignorée lorsqu’elle ne peut pas être évaluée. Les situations suivantes empêchent l’exécution et peuvent conduire à Omission avec une raison :

• Opérateur non pris en charge, par exemple après une modification de la configuration.
• Objet ou champ introuvable, notamment après une suppression ou un changement de nom API.
• Absence d’objet ou d’identifiant de contexte alors qu’un champ de condition est renseigné.
• Enregistrement de contexte supprimé ou non renvoyé par la lecture autorisée.

En cas d’erreur de requête ou d’exécution du contrôle, le parcours temporel peut remettre l’action En attente jusqu’au nombre maximal d’échecs. Le parcours e-mail traite au contraire tout résultat différent d’une condition satisfaite comme Omission, même une erreur temporaire ; il n’applique pas cette boucle de reprise. Dans ce dernier cas, l’omission peut aussi annuler les autres actions en attente du groupe.

Sans Champ de condition, cette vérification est omise. L’opération reste soumise à ses paramètres, accès et autres contrôles : l’absence de condition ne garantit pas son succès.

Groupes et annulations

Une clé de groupe permet d’écarter des actions apparentées après la résolution de l’une d’elles. Ce mécanisme réduit les opérations redondantes, mais ne garantit pas une exécution unique face à des traitements simultanés ou à un échec d’enregistrement de l’annulation.

Exemple

Un utilisateur prévoit deux rappels :

1. Action A : « Envoyer un rappel si aucune réponse n’est enregistrée dans 3 jours. »
2. Action B : « Envoyer un rappel si aucune réponse n’est enregistrée dans 5 jours. »

Avec la même clé de groupe, le succès de A à son échéance peut annuler B encore en attente. Une réponse reçue avant trois jours ne fait pas exécuter A automatiquement. Pour que cette réponse annule les rappels, configurez une action Email_Reply liée au même groupe ou un autre parcours approprié, puis testez ses conditions et ses résultats.

Fonctionnement

• Après le succès d’une action temporelle, le traitement recherche les autres actions en attente portant exactement la même clé de groupe, sans filtre supplémentaire par conversation.
• Il tente de les passer à Annulé, pas à Omission. Une action déjà exécutée ou en cours ne peut pas être annulée rétroactivement par ce simple changement d’état.
• Vérifiez les statuts et les opérations réellement produites, notamment en présence de traitements simultanés ou d’erreurs de mise à jour.

Reprises après échec

Les reprises dépendent du déclencheur. Pour une action temporelle qui échoue, par exemple à cause des données ou autorisations :

• Nombre : le compteur peut atteindre 3 échecs au total avant l’état final Échoué. Nombre de tentatives est incrémenté lors des échecs, pas lors de chaque succès.
• Reprise : avant le troisième échec, le statut repasse à En attente. L’action reste admissible au prochain passage temporel, prévu toutes les 15 minutes à :00, :15, :30 et :45, sous réserve de l’exécution réelle des travaux.
• Pas d’espacement progressif configuré : le traitement ne programme pas des délais croissants entre les reprises. Trois passages espacés de 15 minutes peuvent couvrir environ 45 minutes dans un exemple nominal, mais ce n’est ni une durée garantie ni un calendrier applicable aux actions Email_Reply.
• Au troisième échec temporel : l’action passe à Échoué et le traitement prévoit un journal d’incident avec le nom, type, description, contexte, compteur et échéance. Vérifiez que l’état et le journal ont effectivement été enregistrés.

Un statut Échoué mérite un diagnostic des erreurs et effets réels. Il ne prouve pas qu’un problème est permanent : les accès, indisponibilités ou données peuvent encore évoluer. Les reprises d’une réponse e-mail nécessitent un nouveau traitement de réponse correspondante et ne sont pas prises par ce lot temporel.

Traitement des échéances

La configuration fournie prévoit un traitement toutes les 15 minutes, avec quatre planifications à :00, :15, :30 et :45. Contrôlez qu’elles existent et s’exécutent ; une seule planification présente ne prouve pas que les quatre sont actives.

Actions temporelles

• Le lot sélectionne les actions En attente de type Time_Based ou sans type, dont l’échéance est atteinte et le compteur inférieur à trois.
• Il vérifie la condition éventuelle, puis tente l’opération avec les paramètres et le contexte d’accès applicables.
• En cas de succès, il enregistre Exécuté. En cas d’échec admissible à une reprise, il revient à En attente, puis enregistre Échoué après le troisième échec. Vérifiez les effets réels si l’écriture du statut échoue.

Actions sur réponse e-mail

• Le flux de réception appelle le gestionnaire d’e-mails entrants lorsque le suivi est activé. Le lot temporel ne scrute pas les boîtes aux lettres.
• Le gestionnaire place un travail asynchrone qui rapproche les e-mails et les actions en attente. Ce travail suit sa propre file, pas une garantie d’exécution immédiate.
• Si Traitement par IA est activé, l’analyse utilise le prompt renseigné ou celui par défaut. Une erreur de lecture de la décision ou une décision négative peut conduire à Omission ; examinez la raison et les annulations de groupe associées.

Actions d’e-mail, d’enregistrement et de planification

Les actions d’e-mail distinguent le destinataire Contact ou Piste de l’enregistrement métier associé, acceptent des listes À/Cc et vérifient les cas de refus d’e-mail pris en charge. Un Contact/Piste fourni comme enregistrement associé est traité comme destinataire. Les confirmations montrent les champs non appliqués. Les étapes du plan sont rapprochées une à une et les heures relatives conservent UTC. Les agents désactivés et actions imbriquées non autorisées sont vérifiés avant confirmation. La confirmation de liaison de fichiers réutilise le chemin avec contrôle d’accès. Les nouvelles actions horaires en attente ou replanifiées exigent un processeur disponible ; suivi des réponses et mises à jour normales d’historique/statut restent valides. Les travaux différés utilisent leur propriétaire de planification, sans usurper le demandeur. Les instructions réduisent les doublons via d’autres connecteurs, sans garantir le comportement de l’assistant.

Questions fréquentes