Actions de lien

La famille link crée un lien court suivi pendant l'exécution d'un workflow, et transmet son adresse à l'étape suivante. Le lien de campagne d'un produit qui n'existait pas au moment du déploiement ne peut pas être déclaré en configuration ; c'est ainsi qu'on le fabrique. Trois opérateurs.

# Annoncer un produit dès sa création
- name: mint
  type: link
  operator: create
  props:
    slug: 'product-{{trigger.record.handle}}'
    destination: 'https://example.com/products/{{trigger.record.handle}}'
    title: '{{trigger.record.name}} — lancement'
    utm: { source: newsletter, medium: email, campaign: launch }

# L'envoyer
- name: announce
  type: email
  operator: send
  props:
    to: '{{trigger.record.owner_email}}'
    subject: 'Votre lien est en ligne'
    body: '{{steps.mint.result.shortUrl}}'

L'adresse reçue par l'étape suivante

create et update renvoient quatre champs ; delete renvoie slug et changed.

Les modèles sont résolus d'abord, vérifiés ensuite

Chaque prop de type chaîne est un modèle. slug, destination, title, notes ainsi que chaque entrée de tags et utm sont interpolées contre le déclencheur et les étapes précédentes, et c'est la valeur résolue qui est validée.

C'est cet ordre qui rend l'action sûre à templater librement. Un slug est vérifié contre les règles de slug après que {{trigger.record.handle}} est devenu atlas : un enregistrement dont le handle vaut Pas Un Slug ! fait donc échouer l'étape au lieu d'enregistrer une adresse que personne ne peut atteindre. Une destination est vérifiée de la même façon : la valeur résolue doit être un chemin relatif à la racine ou une URL http(s) absolue, si bien qu'une valeur javascript: ou data: arrivant par un champ d'enregistrement est refusée plutôt que publiée.

Deux slugs qu'une automatisation ne peut jamais prendre

Les deux refus font échouer l'étape en nommant la raison : un run en échec indique donc lequel des deux s'est produit.

Le premier est le plus important. La configuration est la source de vérité pour les liens qu'elle déclare, et une automatisation capable d'en écraser un reviendrait à muter la configuration par une porte dérobée en forme de données. update et delete refusent un slug déclaré en configuration pour la même raison — ils ne peuvent toucher que des liens créés à l'exécution.

LINK_SLUG_TAKEN est un refus, pas un écrasement : créer deux fois le même slug conserve le premier lien. Réorienter une adresse déjà partagée, et réattribuer les clics qu'elle a déjà obtenus, n'est pas ce qu'un déclencheur répété doit faire par accident. Utilisez update quand la réorientation est bien votre intention.

Ajoutez continueOnError: true à l'étape si un refus ne doit pas arrêter le workflow.

La suppression conserve l'historique

delete est une suppression en douceur. Le lien cesse de résoudre et répond 404, et chaque clic déjà obtenu reste dans l'analytique, rapporté sous le même slug. Une suppression définitive détruirait l'historique de campagne en même temps que le lien.

Supprimer deux fois est un succès, pas un échec — le second appel rapporte changed: false, si bien qu'un workflow rejoué ne casse pas. Un slug retiré peut être recréé plus tard.

Il n'y a pas de renommage. Le slug est l'adresse que porte déjà chaque partage et la clé sous laquelle chaque clic est enregistré : le changer casserait les partages et orphelinerait l'historique d'un même geste. Créez plutôt un nouveau lien.

Pages connexes

• Liens courts — déclarer des liens en configuration, et leur résolution.
• Vue d'ensemble des actions — le modèle d'action et les props de base.
• Analytique — où sont rapportés les clics obtenus par ces liens.
• E-mails et notifications — l'étape qui envoie généralement l'adresse créée.