Décrivez un ciblage en français, comme à un collègue : Salta écrit le workflow Adobe Campaign Classic à coller dans la console, avec les requêtes, enrichissements et dédoublonnages. Il s'appuie sur la description de vos tables, n'accède jamais à votre instance, et utilise votre propre clé API Anthropic : ce qui est envoyé est détaillé dans Profil.
Version bêta. L'outil peut se tromper ou manquer un cas. Relisez ce qu'il produit et testez-le hors production avant de vous en servir pour de bon.
Trois informations qui changent la façon d'écrire les workflows. Elles se trouvent dans Aide › À propos.
Aide › À propos, dans la console, donne la version exacte.
Ce que Salta sait construire : requête, split, enrichissement, livraison, et les activités propres à ton instance. Cette liste n'est pas devinée, elle est lue dans la définition même de tes workflows. Un jeu de base est fourni pour les activités de contrôle de flux ; charge la définition de ton instance pour avoir le reste.
Où les trouver. Dans la console : Administration › Configuration › Schémas de données, ouvre le schéma voulu, puis l'onglet Preview. C'est celui qui fusionne tout, pas l'onglet source.
Deux définitions à charger, l'une après l'autre : xtk:workflow pour les activités, xtk:queryDef pour les critères de ciblage. Tu peux aussi déposer le formulaire xtk:workflow pour récupérer les libellés de la palette.
| activité | nom métier | sorties | à renseigner | source |
|---|
La structure vient du schéma, pas d'ici. Ce que Salta apprend de tes workflows, c'est ta façon de faire : l'écartement des boîtes sur le canevas, l'enveloppe de package, et la forme des activités qu'il ne connaît pas encore. Colle un workflow existant, exporté ou simplement copié depuis le canevas. Salta en déduit les balises, les attributs, et distingue ce qui varie de ce qui est structurel. Un attribut ne devient un paramètre que s'il a été vu prendre plusieurs valeurs : deux ou trois workflows suffisent à trancher.
Aucune source pour l'instant.
Comment tes workflows relient les boîtes entre elles, et à quel écartement ils les posent sur le canevas. Vérifie que ça correspond à ce que tu vois dans tes exports.
Servent uniquement de secours pour les activités que la définition d'instance ne décrit pas encore.
Les tables et les champs sur lesquels tu cibles. Sans eux, Salta ne peut pas vérifier qu'un critère existe vraiment, et l'IA doit deviner sur quelle table travailler.
Salta n'a aucun accès à ton instance, et c'est voulu. Il écrit le script, tu l'exécutes toi-même dans une activité JavaScript d'un workflow de test, puis tu rapportes le journal ici. Le script ne modifie rien et n'affiche que des noms de champs, jamais une donnée client.
Bonus : il suit aussi les tables reliées à celle que tu demandes, comme les achats ou la fidélité, sans que tu aies à les nommer.
Désactivé par défaut. Activé, le script lit en base les valeurs distinctes de ces champs, jamais un email, un nom, un téléphone ni une adresse, et rien au-delà de 20 valeurs. C'est une lecture de données : à n'activer qu'avec l'accord du client. En échange, Salta écrit « OCC » plutôt que « L'Occitane ».
| champ | type | libellé | table |
|---|
Aucun schéma chargé.
Tout ce que Salta a appris de ton instance tient dans un fichier. Une personne configure, exporte, et le reste de l'équipe importe. Plus personne ne refait la mise en route.
Sans les sources, l'export ne contient que la structure déduite. Décoché par défaut : ces XML viennent d'instances clientes.
Salta a besoin d'une clé API Anthropic pour lire ta demande en français et en déduire la forme du workflow : quelles activités, dans quel ordre, avec quelles branches, et le découpage de ta demande en critères de ciblage. Tout le reste, la structure XML et la résolution des champs dans tes tables, se fait sans modèle.
Sans clé, le bouton Rédiger ne fonctionne pas. Tu peux encore construire un workflow à la main depuis la vue Détail, mais tu perds l'essentiel de l'outil.
Décoché, la clé reste en mémoire le temps de l'onglet. Coché, elle est gardée dans ce navigateur. Elle n'est jamais incluse dans l'export du profil.
Quand tu cliques sur Rédiger, ton navigateur envoie directement à Anthropic (Claude), avec ta clé :
Ne part jamais : le contenu de ta base (aucune ligne de données), le XML complet d'un workflow repris, ta clé ailleurs que chez Anthropic. Salta n'accède jamais à ton instance. Grokium ne reçoit ni ta demande, ni tes tables, ni ta clé, sauf ce que tu choisis d'envoyer dans un avis ou un signalement.
Chez Anthropic, les échanges passent par l'API sous ton compte : ce sont tes conditions Anthropic qui s'appliquent (par défaut, les données de l'API ne servent pas à entraîner les modèles). Si ta demande contient des informations sensibles de ton client, reformule-la ou vérifie d'abord que ce transfert est autorisé chez lui. Politique de confidentialité
Décris ce que tu veux obtenir. Salta rédige le XML, le vérifie contre ton instance, et te dit ce qu'il n'a pas pu décider seul.
Relis le workflow et teste-le sur une copie ou un petit échantillon avant de le lancer en production : Salta aide, il ne remplace pas ta vérification.
Les activités et leurs liens tels qu'ils arriveront dans la console. En rouge, une activité en erreur ; en orange, une activité qui attend ta réponse.
Ces valeurs décident du sens du workflow : Salta ne les invente pas, et le modèle a préféré demander. Renseigne-les ici, le XML se régénère aussitôt.
Chaque critère de ta demande, et le champ retenu dans tes tables. Rien à valider : corrige seulement si un choix te paraît faux.
Colle un workflow exporté, ou ses activités copiées depuis le canevas. Salta le reprend dans le Détail ; décris ensuite la modification dans Demande et clique sur Rédiger. Les activités que le modèle ne touche pas ressortent telles quelles, avec tous leurs réglages ; seuls leurs liens et leurs clés internes sont mis à jour.
Colle ici le message d'erreur de la console ou le journal du workflow. Salta reconnaît l'erreur, retrouve l'activité concernée dans ce workflow, et peut relancer la rédaction en donnant l'erreur exacte au modèle.
Chaque activité a un identifiant court, un type, un libellé et ses réglages. Les liens entre activités se déclarent à part, dans edges. Voici un exemple construit avec les activités de ton instance.
Gardées dans ce navigateur seulement, jamais dans le profil exporté. Reprendre remet la demande et le détail tels qu'ils étaient.
Ta demande, plus le contexte ci-dessous, tiré de ton profil. Aucune ligne de ta base : des noms d'activités, de tables et de champs, leurs libellés et valeurs de liste.