Demandes

Décisions et approbations

Beaucoup de demandes existent pour obtenir une seule chose : un oui, un non, ou un « pas comme ça ». La question de décision capture ce verdict dans une forme sur laquelle votre automatisation peut brancher directement, sans deviner quel champ contenait la réponse.

Pourquoi une question spéciale

Chaque choix a déjà une clé d’option, donc un flux de travail peut brancher sur n’importe quel bouton radio. Ce qu’un flux de travail ne peut pas faire, c’est savoir, à travers tous les formulaires ayant une approbation, quelle clé signifie « oui » : le bouton radio d’un auteur dit sign_off, celui d’un autre approved.

La question de décision fixe les noms. C’est une question à choix unique avec la clé de champ decision, dont les trois options portent les clés d’option approve, decline et changes. Leurs libellés restent à vous pour les reformuler et les traduire ; les clés en dessous ne bougent jamais. Quand le destinataire en choisit une, la demande se termine avec un résultat. Tout bouton radio à la clé decision dont les options portent ces trois clés compte — le préréglage ne fait que les définir pour vous.

Ajouter une décision à votre formulaire

1
Ouvrez le menu de blocs
Appuyez sur / dans l'éditeur et choisissez Décision — « Approuver, refuser, ou demander des modifications ».
2
Reformulez les libellés
Vous obtenez une question intitulée « Approuvez-vous ? » avec les choix Approuver, Refuser, et Demander des modifications. Réécrivez-les comme vous voulez — « Valider », « Rejeter », « Renvoyer pour correction ». Traduisez-les comme n'importe quel autre contenu.
3
Demandez pourquoi, si nécessaire
Un verdict seul s’explique rarement. Ajoutez une question de texte long juste après, et n’affichez-la que pour refuser et modifications avec la logique conditionnelle.
4
Publiez
Les demandes créées à partir de cette version publiée se terminent avec un résultat. Comme toute clé de champ, decision n'existe qu'une fois le formulaire publié.

Seul le préréglage produit un résultat

Le résultat est lu depuis la question dont la clé de champ est decision, et seulement quand la clé de l’option choisie est l’une des trois. Un bouton radio que vous construisez à la main avec des options intitulées Approuver, Refuser et Modifications dérive exactement ces clés, donc il fonctionne sans le préréglage ; un bouton radio avec d’autres libellés fonctionne une fois que vous tapez les trois clés dans le tableau Clés.

Supprimez l’une des trois options, ou retapez sa clé, et la publication vous avertit : « La question de décision n’a pas d’option Approuver, Refuser ou Demander des modifications, donc les demandes peuvent se terminer sans résultat. » Les trois doivent être présentes — une décision qui ne peut qu’approuver ne peut pas refuser.
Une question de décision à l’intérieur d’un groupe répétable est une question ordinaire et est ignorée pour le résultat.

Les trois valeurs

Valeur	Libellé par défaut	Signifie
approve	Approuver	Le destinataire a accepté. Votre exécution continue sur le chemin nominal.
decline	Refuser	Il a dit non. La demande se termine quand même — refuser est un verdict, pas un échec.
changes	Demander des modifications	Il veut que quelque chose soit modifié avant d'accepter. Généralement le signal pour envoyer une nouvelle demande.

Ces trois valeurs forment un contrat public, comme une clé de champ : une automatisation, un agent et une formule de tableur les lisent tous. Ajouter une quatrième option et la choisir est une réponse ordinaire, pas un verdict — cette demande se termine sans résultat, plutôt qu’avec une valeur que votre récepteur n’a jamais rencontrée.

Où apparaît le résultat

Surface	Ce que vous obtenez
Callback	outcome dans le bloc request de la charge utile request.completed — absent quand il n'y a pas de verdict.
requests.get	outcome à côté de status, plus les réponses classées par clé de champ.
requests.list	Un filtre outcome ; en passer un implique les demandes terminées uniquement.
Page Demandes	Un filtre Résultat, et Approuvée / Refusée / Modifications demandées sur la demande elle-même.
Soumissions	Le verdict est aussi une réponse ordinaire, sous la clé de champ decision.

request.completed, tronqué

json

{
  "id": "evt_...",
  "type": "request.completed",
  "test": false,
  "data": {
    "request": {
      "id": "kd7...",
      "externalId": "run-42",
      "status": "completed",
      "outcome": "changes",
      "context": { "case_id": "CASE-9" }
    },
    "answers": {
      "decision": "changes",
      "reason": "Please split the line items per site."
    }
  }
}

Branchez sur data.request.outcome. status indique si la demande s’est terminée ; outcome indique ce que le destinataire a décidé. Une demande expirée ou annulée a un statut et aucun résultat, tout comme une demande terminée sur un formulaire sans question de décision.

Depuis un agent

L’outil MCP est editor_insertDecisionQuestion, qui prend un titre et les trois libellés dans la langue du formulaire. Un agent qui ne peut pas héberger de point de terminaison de callback interroge plutôt request_get et lit outcome quand le statut quitte pending. Demandes sur le serveur MCP →

Callbacks et signatureLa charge utile complète et comment la vérifier.La page DemandesFiltrez par résultat et suivez une demande.Logique conditionnelleDemandez une raison uniquement quand c'est nécessaire.Types de questionsToutes les autres questions que vous pouvez poser.