Ce guide montre comment construire une procédure Fin réutilisable qui consulte un catalogue produit via votre API, correspond à l'article demandé par un client, vérifie le stock et oriente le flux selon la disponibilité. Vous pouvez utiliser cette procédure pour créer de nouvelles commandes ou mettre à jour les existantes via vos API de commande backend.

Conservez vos propres points de terminaison API et noms de paramètres — remplacez les URL d'exemple, corps de requête et noms de champs par ceux exposés par votre backend. Si vous n'avez jamais créé de procédure, lisez d'abord Building Fin Procedures.

Note :

Connecteurs de données : Vous avez besoin de trois connecteurs spécifiques :
- Un pour retourner un catalogue produit (GET).
- Un pour créer un article de commande (POST).
- Un pour mettre à jour une commande existante (PUT).
Structure de réponse canonique : Vos API doivent retourner une structure de données cohérente.
Gestion des erreurs : Pour une procédure robuste, vos étapes Condition doivent utiliser les attributs de réponse status_code et error retournés par les connecteurs de données. Cela permet à Fin de bifurquer selon des codes d'erreur HTTP spécifiques (ex. 400, 500) plutôt que de se fier à un chemin générique réussite/échec.

Conseil : Connectez-vous avec des experts de la communauté et des architectes solutions Intercom lors de nos heures de bureau Procedures Meetup. Ces sessions, tenues toutes les deux semaines, offrent un support pratique en temps réel, incluant une séance de questions-réponses pour vous aider à configurer et optimiser vos procédures Fin et connecteurs de données.

Configuration des connecteurs de données

Créez trois connecteurs avec des noms clairs (par exemple, Get Product Catalog, Create Order Item, Update Order Item) pour aider Fin à identifier l'action correcte.

Rassemblez toutes les entrées nécessaires au connecteur. Les attributs temporaires peuvent désormais être passés directement comme entrées à un connecteur de données — si les données existent déjà dans une variable temporaire, Fin les mappe automatiquement sans demander au client. Configurez une entrée comme collectée auprès du client uniquement si la valeur n'est pas déjà stockée. Remplacez https://api.example.com et les noms de champs par vos propres points de terminaison et clés JSON. Pour les questions fréquentes sur la configuration, l'authentification et l'exécution des connecteurs, consultez Fin and Data connectors FAQs.

1. Get Product Catalog (GET)

Objectif : Retourne une liste de produits incluant id, nom, prix et stock.
Méthode : GET.
URL : https://api.example.com/items (ou votre point de terminaison catalogue)
En-têtes : Content-Type : application/json (+ auth selon besoin)

Réponse : Un tableau d'objets produit.

Example response:

[
  { "id": "sku-100", "name": "Classic T-Shirt", "price": 19.99, "stock": 120 },
  { "id": "sku-101", "name": "Running Shoes",  "price": 89.50, "stock": 45 },
  { "id": "sku-104", "name": "Nintendo Switch", "price": 119.00, "stock": 0 }
]

2. Create Order Item (POST)

Objectif : Crée une nouvelle commande ou un article de commande spécifique.
Méthode : POST.
URL : https://api.example.com/orders (ou votre point de terminaison création de commande)
En-têtes : Content-Type : application/json (+ auth)
Corps de la requête : Doit inclure product_id et quantity.
```
{
  "product_id": "<product id>",
  "quantity": <integer>
}
```
Configurez les entrées du connecteur si vous souhaitez que Fin collecte product_id et quantity.

3. Update Order Item (PUT)

Objectif : Ajoute des articles ou met à jour une commande existante.
Méthode : PUT.
URL : https://api.example.com/orders/{{order_id}} (ou PUT /orders/{order_id}/items)
En-têtes : Content-Type : application/json (+ auth)
Corps de la requête : Doit inclure product_id et quantity.
```
{
  "product_id": "<product id>",
  "quantity": <integer>
}
```
Entrées requises : order_id, product_id, quantity

Connexion API montrant la variable de chemin order_id et le corps de la requête.
Collecte des données d'entrée listant order_id, product_id, quantity.

Construction du flux de procédure

Utilisez des variables temporaires pour stocker des données intermédiaires tout au long de la conversation. Les variables recommandées incluent Temporary.SelectedProductID, Temporary.StockLevel et Temporary.OrderAction.

Étape 1 : Demande et recherche de produit

Invite client : Demandez, « Quel produit souhaitez-vous ? ».
Appeler le connecteur de données : Utilisez Get Product Catalog.
Logique : Cherchez dans la liste retournée un produit dont le nom (ou SKU) correspond le mieux à Temporary.SelectedProductName.
En cas de correspondance, définissez :
- Temporary.SelectedProductID = id du produit
- Temporary.SelectedProductName = nom canonique du produit depuis le catalogue
- Temporary.StockLevel = stock du produit (converti en entier)
Validation : Si aucune correspondance n'est trouvée, invitez le client à clarifier ou suggérez les produits similaires principaux du catalogue et revenez à l'Étape 1 s'il choisit un autre produit.

Notes d'implémentation

La logique de correspondance peut être une simple recherche de sous-chaîne ou une correspondance floue plus sophistiquée. Gardez la correspondance déterministe pour que les étapes Condition de Fin fonctionnent de manière fiable.

Étape 2 : Vérification du stock et branchement

Utilisez un bloc logique standard IF/ELSE dans l'interface de procédure pour vérifier Temporary.StockLevel. Il s'agit d'une comparaison de valeur simple — aucune condition de code n'est nécessaire ici. Utilisez le générateur de conditions visuel et sélectionnez Temporary.StockLevel comme attribut.

IF Temporary.StockLevel > 0 : Passez à l'étape 3.
ELSE : Dirigez vers la section « Rupture de stock » (Étape 8).

Étape 3 : Demander nouvelle commande ou commande existante

Invite : « Souhaitez-vous créer une nouvelle commande pour cet article ou l'ajouter à une commande existante ? »
Accepter les réponses :
- Nouveau → Temporary.OrderAction = « new » → Étape 4
- Existant → Temporary.OrderAction = « existing » → Étape 4
- En cas d'incertitude, posez une question de clarification et répétez.

Étape 4 — Demander la quantité et valider (mise à jour mineure)

Invite : « Combien d'unités souhaitez-vous ? » → analyser l'entier → stocker dans Temporary.Quantity.
Validation :
- Si Temporary.Quantity ≤ 0 → redemander.
- Si Temporary.Quantity > Temporary.StockLevel → informer le client du stock disponible et soit :
  - Proposer le maximum disponible et demander de confirmer une quantité moindre (boucle dans l'étape 4), ou
  - Proposer des options de commande en attente/notification (Étape 8).
Après validation de la quantité, passer à l'étape 5 (Décision d'action de commande).
Blocs d'invite de quantité et d'action de validation.

Étape 5 : Décision d'action de commande (IF / ELSE IF)

Plutôt que de gérer la création et la mise à jour des commandes en ligne, dirigez chaque chemin vers une sous-procédure dédiée. Cela garde le flux principal clair et rend chaque chemin testable indépendamment. Ajoutez un bloc conditionnel IF / ELSE IF, puis utilisez @Run sub-procedure dans chaque branche : Pour des comparaisons complexes ou basées sur des dates, voir Comment écrire des conditions de code pour les procédures Fin.
1. IF Temporary.OrderAction == 'new' : utilisez @Run sub-procedure pour invoquer la sous-procédure Create New Order.
2. ELSE IF Temporary.OrderAction == 'existing' : utilisez @Run sub-procedure pour invoquer la sous-procédure Update Existing Order.
3. ELSE (repli) : escalade à l'équipe

Étape 6 : CRÉER UNE NOUVELLE COMMANDE (sous-procédure)

Déplacez cette étape dans une sous-procédure dédiée (par exemple « Create New Order ») pour garder le flux principal lisible. Dans cette sous-procédure, appelez le connecteur Create Order Item. Les attributs temporaires tels que Temporary.SelectedProductID et Temporary.Quantity peuvent être mappés directement aux entrées du connecteur — aucune invite manuelle nécessaire :
- product_id = Temporary.SelectedProductID
- quantity = Temporary.Quantity
Capturez la réponse dans Temporary.NewOrderID (si renvoyé) et stockez le status_code du connecteur dans Temporary.CreateOrderStatus.
En cas de succès : répondre :
« Nouvelle commande créée avec [Temporary.Quantity] × [Temporary.SelectedProductName]. ID de commande : [Temporary.NewOrderID]. Autre chose que je puisse faire ? »
Proposez des choix post-action (ajouter plus d'articles, changer la quantité, passer à la caisse, terminer). Conservez Temporary.NewOrderID si la session continue.
Ajoutez une étape Condition immédiatement après l'appel du connecteur et branchez-vous sur Temporary.CreateOrderStatus. Le status_code et les attributs d'erreur peuvent apparaître en bas du sélecteur d'attributs — faites défiler si vous ne les voyez pas. Utilisez les branches suivantes : IF status_code == 200 ou 201 : passez à la confirmation de succès. ELSE IF status_code == 400 : informez le client que sa demande est invalide (ex. mauvais ID produit ou quantité), invitez-le à corriger l'entrée et proposez une nouvelle tentative. ELSE IF status_code ≥ 500 : excusez-vous pour une erreur serveur, capturez l'attribut d'erreur dans une note interne pour débogage, et escaladez à l'Équipe Support E-Comm. ELSE (statut inattendu) : enregistrez Temporary.CreateOrderStatus et escaladez à l'Équipe Support E-Comm. Pour un guide approfondi sur le débogage des échecs de connecteurs et l'interprétation des codes de statut, voir Dépannage des procédures Fin et connecteurs de données.
Appel du connecteur avec entrées mappées et mappage de réponse (order_id → Temporary.NewOrderID).
Message de confirmation post-action et options.

Étape 7 : METTRE À JOUR LA COMMANDE EXISTANTE (sous-procédure)

Invite : « Veuillez fournir l'ID de commande existante à laquelle vous souhaitez ajouter cet article. » → enregistrer dans Temporary.ExistingOrderID.
Appel : connecteur Update Order Item avec :
- order_id = Temporary.ExistingOrderID
- product_id = Temporary.SelectedProductID
- quantity = Temporary.Quantity
Capturez le status_code du connecteur dans Temporary.UpdateOrderStatus et le champ d'erreur (si présent) dans Temporary.UpdateOrderError.
En cas de succès : répondre :
« Ajouté [Temporary.Quantity] × [Temporary.SelectedProductName] à la commande [Temporary.ExistingOrderID]. Autre chose ? »
Proposez des choix post-action (ajouter plus d'articles, changer la quantité, passer à la caisse, terminer).
Ajoutez une étape Condition immédiatement après l'appel du connecteur et branchez-vous sur Temporary.UpdateOrderStatus. Comme à l'étape 6, le status_code et les attributs d'erreur peuvent apparaître en bas du sélecteur d'attributs. Utilisez les branches suivantes : IF status_code == 200 : passez à la confirmation de succès. ELSE IF status_code == 400 : informez le client que l'ID de commande peut être invalide, demandez-lui de vérifier et de le ressaisir, et proposez une nouvelle tentative. ELSE IF status_code ≥ 500 : excusez-vous pour une erreur serveur, affichez Temporary.UpdateOrderError dans une note interne, et escaladez à l'Équipe Support E-Comm. ELSE (statut inattendu) : enregistrez le statut et escaladez à l'Équipe Support E-Comm. Voir Dépannage des procédures Fin et connecteurs de données pour un guide complet sur le diagnostic des échecs de connecteurs en conversations en direct.
Astuce : Les attributs status_code et error renvoyés par un connecteur de données peuvent apparaître en bas du sélecteur d'attributs. Faites défiler si vous ne les voyez pas immédiatement — ils sont essentiels pour construire des branches de gestion d'erreurs robustes.
Collecte de ExistingOrderID et appel du connecteur Update qui l'utilise.
Message de confirmation post-action et options.

Étape 8 : RUPTURE DE STOCK

Déclenchement lorsque Temporary.StockLevel ≤ 0 ou lorsque la quantité demandée > disponible et que le client refuse une quantité réduite.
Actions :
1. S'excuser et présenter des options claires :
  - Afficher des produits similaires (meilleures correspondances du catalogue).
  - Proposer la commande en attente/notification lorsque disponible — enregistrer la préférence de contact.
  - Proposer une quantité partielle si disponible.
2. Si le client choisit notification/commande en attente → enregistrer la préférence et confirmer.
3. Si le client choisit une alternative → revenir à l’étape 1 (demande et recherche de produit) avec la nouvelle sélection.
4. Terminer ou boucler selon la réponse du client.

Étapes suivantes

Une fois votre flux de commande principal opérationnel, envisagez ces modèles avancés pour gérer des résultats plus complexes.

Transférer à un Workflow après la création de la commande

Après une nouvelle commande réussie, transférer à un Workflow (par exemple « Send Order Confirmation ») pour gérer l’automatisation en aval comme les reçus par email ou les mises à jour CRM. Utilisez une étape Handoff to workflow à la fin de votre sous-procédure Créer une nouvelle commande. La procédure se termine au transfert et ne reprend pas après la fin du Workflow, faites donc de cette étape la dernière.

Changer de procédure selon le résultat de la commande

Si la commande aboutit à un état spécifique — par exemple une commande en attente ou un paiement échoué — basculer vers une procédure dédiée (par exemple « Backorder Management » ou « Payment Failure Recovery ») plutôt que de gérer tous les résultats dans une seule procédure. Cela permet de garder les procédures individuelles ciblées et plus faciles à maintenir.

Escalader avec contexte en cas d’échecs répétés d’API

Si le même connecteur échoue lors de la nouvelle tentative (par exemple deux erreurs 500 consécutives), escalader vers une équipe humaine et inclure une note interne résumant Temporary.CreateOrderStatus ou Temporary.UpdateOrderError pour que le coéquipier ait tout le contexte sans avoir à redemander au client.

Chaîner les sous-procédures pour les paniers multi-articles

Pour permettre aux clients de commander plusieurs produits en une session, revenir à la sous-procédure Demande de produit après une action de commande réussie et incrémenter un compteur d’articles. Terminer la boucle lorsque le client confirme qu’il a fini.

Créer une procédure Fin complexe