Automation Studio : l'import qui a relancé 9 000 anciens clients

Une mutuelle envoie chaque matin un rappel de cotisation aux adhérents en retard de paiement. L'automation démarre à 5 h, récupère deux fichiers sur le SFTP, les importe, construit l'audience en excluant les contrats résiliés, puis lance l'envoi. Elle tourne depuis deux ans sans faire parler d'elle.

Un mardi, le traitement qui produit le fichier des résiliés est interrompu par une maintenance. Le fichier déposé contient 14 lignes au lieu d'environ 9 000. L'import, configuré en mode Overwrite directement sur la table de production, remplace la liste complète par ces 14 lignes. La requête d'audience s'exécute sans erreur. L'envoi part. Environ 9 000 anciens adhérents reçoivent une demande de paiement pour un contrat qu'ils ont résilié.

Le tableau de bord d'Automation Studio affiche une exécution réussie. Aucune alerte n'est partie, puisque aucune activité n'a échoué. Le service client découvre le problème à 9 h, au premier appel.

Un import réussi n'est pas un import correct

Un import de 14 lignes est un import réussi. Une requête qui écrit zéro ligne est une requête réussie. Automation Studio surveille le déroulement technique de chaque activité, pas la cohérence des données qui y transitent. Les statuts qu'il remonte se lisent avec cette limite en tête.

Les erreurs détectées par la plateforme

Les erreurs que la plateforme sait détecter sont documentées : doublons sur la clé primaire et dépassement des 30 minutes pour les requêtes, fichier introuvable ou vide pour les imports, identifiants SFTP refusés pour les transferts. Les activités Script sont soumises à la même limite de 30 minutes. Rien dans cette liste ne couvre un fichier parfaitement formé mais incomplet.

Des étapes, pas des branches

Une automation est une suite d'étapes, et chaque étape contient une ou plusieurs activités. Trailhead pose l'avertissement dans l'autre sens : une activité qui lit une data extension ne doit pas être placée dans la même étape que la requête qui la remplit, sinon elle ne trouve rien. Les activités d'une même étape ne s'attendent pas les unes les autres, donc tout ce qui dépend d'un résultat va dans une étape suivante.

Une fois ce découpage assimilé, l'automation de la mutuelle prend une autre forme.

Nommer les activités par préfixe

Nommez les activités avec un préfixe par type (QRY_, IMP_, FTP_, VER_) et rappelez le nom de l'automation dans la description. Six mois plus tard, devant une liste de deux cents activités, cette convention est ce qui permet de lire une automation sans l'ouvrir.

Importer dans une table de transit

La correction de fond tient en un principe : un fichier n'écrase jamais une table dont l'envoi dépend. Les données arrivent dans une table de transit, les contrôles se font sur cette table, et la table de référence n'est mise à jour qu'ensuite, par une requête.

IMP_Resilies           : fichier          -> Resilies_Import  (Overwrite)
VER_Resilies_Min       : Resilies_Import  < 1 000 lignes  -> arrêt
QRY_Resilies_Reference : Resilies_Import  -> Resilies       (Overwrite)

Le bénéfice se voit le jour de l'incident. Comme la table de référence n'a pas bougé, une relance complète après le dépôt du bon fichier ne présente aucun danger, et vous n'avez pas à reconstituer la veille à partir d'un export.

Arrêter sur un volume anormal

L'activité Verification évalue une data extension selon des conditions que vous fixez, le plus souvent un nombre de lignes minimal ou maximal. Quand la condition est rencontrée, elle arrête l'automation, envoie un email, ou les deux, avec une note que vous rédigez. Elle obéit à quelques contraintes documentées : elle appartient à une seule automation et ne se réutilise pas ailleurs, plusieurs activités Verification peuvent partager une étape mais aucune autre activité ne peut s'y trouver, et elle porte sur n'importe quelle data extension, pas seulement sur les cibles des activités de l'automation.

Au-delà du simple nombre de lignes

Son contrôle se limite à un nombre de lignes. Pour une règle plus fine, un volume qui s'effondre par rapport à la table de référence, un montant négatif, une date incohérente, on combine deux objets : une requête qui n'écrit une ligne que lorsque la règle est violée, et une Verification qui arrête l'automation dès que cette table de contrôle n'est pas vide.

SELECT
    'RESILIES_VOLUME'                        AS Controle,
    CONCAT('Import : ', i.NbImport,
           ' lignes, reference : ', r.NbReference,
           ' lignes')                        AS Detail,
    GETDATE()                                AS DateControle
FROM (SELECT COUNT(*) AS NbImport    FROM Resilies_Import) AS i
CROSS JOIN
     (SELECT COUNT(*) AS NbReference FROM Resilies)        AS r
WHERE i.NbImport < r.NbReference * 0.8

UNION ALL

SELECT
    'RETARDS_MONTANT'                        AS Controle,
    CONCAT(COUNT(*), ' montants nuls ou negatifs') AS Detail,
    GETDATE()                                AS DateControle
FROM Retards_Import
WHERE Montant <= 0
HAVING COUNT(*) > 0

Chaque sous-requête renvoie une ligne unique, ce qui rend le CROSS JOIN sans risque. La première partie ne renvoie rien tant que le volume reste normal, la seconde ne renvoie rien tant qu'aucun montant n'est anormal, grâce au HAVING. Le seuil de 80 % est un choix métier. Un volume de résiliés baisse rarement de quelques pour cent en une nuit, et au-delà, mieux vaut qu'un humain regarde avant l'envoi.

Le montage repose sur un comportement à vérifier chez vous : en mode Overwrite, une requête qui ne renvoie aucune ligne devrait laisser la table de contrôle vide, et donc laisser passer la suite. Provoquez le cas en recette avant de compter dessus.

Journaliser, prévenir, reprendre

Quand les contrôles passent, une requête écrit une ligne par table dans un journal d'exécution, en mode Append et sans clé primaire, pour garder une trace par exécution.

SELECT 'AUTO_Relance_Cotisation' AS Automation,
       'Resilies_Import'         AS Etape,
       COUNT(*)                  AS NbLignes,
       GETDATE()                 AS DateExecution
FROM Resilies_Import

UNION ALL

SELECT 'AUTO_Relance_Cotisation',
       'Retards_Import',
       COUNT(*),
       GETDATE()
FROM Retards_Import

Dans un UNION ALL, les noms de colonnes viennent de la première requête, les alias suffisent donc en tête. Au bout de quelques semaines, ce journal donne le volume habituel de chaque fichier, et vos seuils reposent sur des chiffres plutôt que sur une intuition. Prévoyez une rétention sur la data extension pour qu'elle ne grossisse pas sans fin, et souvenez-vous que GETDATE() renvoie l'heure du serveur Marketing Cloud, pas celle de Paris.

Régler les alertes par automation

Chaque automation a ses propres réglages de notification, avec les adresses à prévenir quand une exécution est sautée, quand elle rencontre une erreur ou quand elle se termine, et une note facultative ajoutée au message. Renseignez une boîte partagée de l'équipe, jamais l'adresse du consultant qui a construit l'automation, et testez l'alerte en provoquant volontairement une erreur en recette. Salesforce propose aussi l'Event Notification Service pour transmettre ces événements par webhook à un outil de supervision.

Côté démarrage, trois sources existent : la planification, le dépôt d'un fichier sur l'Enhanced FTP et le déclencheur sur un stockage externe comme AWS S3 ou Azure. Pour les deux dernières, les fichiers sont mis en file d'attente par défaut, chacun attend son tour. Si vous désactivez la file, les fichiers qui arrivent pendant une exécution sont ignorés, ce qui est une belle façon de perdre un dépôt sans le savoir.

Écrire la procédure de reprise

La procédure de reprise s'écrit avant d'en avoir besoin, et elle tient en quelques lignes :

1. lire la table des anomalies et le journal d'exécution pour identifier la cause ;
2. obtenir un fichier corrigé, ou décider de ne pas envoyer ce jour-là ;
3. relancer l'automation avec Run Once une fois le fichier redéposé ;
4. vérifier dans le journal que les volumes sont revenus à la normale ;
5. consigner l'incident et ajuster les seuils si nécessaire.

Si vous venez d'Adobe Campaign

Une automation joue le rôle d'un workflow technique, avec une différence de structure qui déroute au début : pas de transitions ni de branches, une simple liste d'étapes. L'embranchement conditionnel n'existe pas, et on le remplace par une activité Verification ou par un script qui décide de la suite.

Dans Campaign, les propriétés d'exécution du workflow permettent de choisir entre suspendre et ignorer en cas d'erreur, et une activité peut disposer d'une transition d'erreur. Le contrôle de volume que vous faisiez avec un test sur le nombre d'enregistrements d'une transition devient une activité Verification, placée seule dans son étape, et vos alertes se règlent automation par automation.

Le réflexe à garder

Devant une automation qui alimente un envoi, cherchez l'endroit où un fichier incomplet passerait sans bruit, et posez la question à voix haute : que se passe-t-il si le dépôt de ce matin contient dix lignes ? Tant que la réponse est « l'envoi part quand même », le contrôle qui manque coûte moins cher à écrire qu'un matin passé au téléphone avec le service client.

Questions fréquentes