Parcours utilisateurs
Un parcours utilisateur est la surface par laquelle un participant prend part à un Processus Ormuz. Il présente les actions qui lui sont destinées, reflète la progression du Processus et renvoie des réponses validées au même contexte d'exécution.
Le parcours suit le Processus
Le parcours utilisateur ne porte pas une logique métier parallèle. Les appels providers, Decisions, Agents, règles de routage et étapes automatiques restent dans le Processus. Lorsque celui-ci atteint une Action utilisateur, le parcours présente l'interaction au participant autorisé et le Processus attend durablement sa résolution.
Cette séparation permet à une même opération de combiner systèmes, automatisation et interactions humaines sans reconstruire un moteur de parcours front indépendant. Fermer la page ne supprime pas l'état du Processus : l'instance reste la source de vérité de ce qui attend et de ce qui doit suivre.
Le Processus atteint une Action utilisateur, le parcours présente l’interaction au participant, puis la complétion typée permet à la même instance de reprendre.
Actions utilisateur, formulaires et interactions provider
Le parcours ne possède pas son propre catalogue d'écrans : il rend les nodes d'interaction présents dans le Processus. Le catalogue des nodes reste la source de vérité des contrats disponibles, y compris les interactions fournies par les extensions.
| Besoin | Contrat recommandé |
|---|---|
| Collecter des valeurs avec un formulaire réutilisable | custom_form référence une ressource Form choisie à la conception. |
| Construire les questions pendant l'exécution | dynamic_form consomme un common.form_spec produit au runtime. |
| Présenter un choix, un consentement ou un contenu | Utilisez l'Action utilisateur Core correspondant au contrat attendu. |
| Faire intervenir un provider dans le navigateur | Utilisez le node de l'extension ; le Processus conserve l'attente et la reprise autour de l'interaction. |
Un dynamic_form peut par exemple recevoir un common.form_spec produit par
une activité Agent après analyse d'un dossier. La soumission est validée contre le formulaire
réellement présenté puis revient comme common.form_submission. Le formulaire dynamique
ne crée pas silencieusement une ressource Form persistante.
L'Action utilisateur est une étape du Processus. Le parcours utilisateur est la surface qui peut présenter plusieurs de ces actions au fil de la même instance.
Progression et phases métier
Un Processus peut demander plusieurs interactions à la même personne : identité, informations entreprise, clarification, acceptation de conditions, etc. Le parcours projette l'état réel du Processus en une progression lisible au lieu de maintenir un second état côté interface.
Les interactions peuvent être regroupées en phases nommées. Une phase organise la présentation ; elle ne modifie ni l'ordre d'exécution ni les règles du Processus.
Les phases donnent une lecture métier des interactions visibles sans créer un second moteur de parcours.
Le Process Builder peut proposer des phases à partir des interactions déjà présentes dans le graphe. Cette génération reste une action dédiée et le résultat demeure une configuration du parcours.
Accès participant borné à une instance
Un participant accède à son parcours avec une capacité temporaire liée à une instance de Processus et à une identité de participant précise. Cet accès n'est pas une session générale sur la plateforme.
Créer un lien depuis une instance
POST /v1/process-instances/{instance_id}/journey-linkLa réponse expose notamment url, token_id, participant_key et
expires_at. Lorsque le cas d'usage exige une durée spécifique, fournissez
expires_in_seconds à la création du lien.
Certains objets métier, comme une checkout_session, peuvent exposer directement l'URL
correspondant au parcours associé. Dans tous les cas, la portée reste celle du participant et de
l'instance concernés.
Ne partagez pas cette URL comme un lien public générique. Elle autorise les interactions prévues pour ce participant dans ce contexte de Processus, pas un accès arbitraire aux objets, à l'API ou à la Console.
Le parcours peut être rendu par Ormuz
Ormuz peut héberger la page qui présente le parcours. Selon le contexte produit, vous pouvez rediriger le participant vers l'URL fournie ou l'embarquer dans une zone compatible de votre interface. L'hébergement est un mécanisme de diffusion ; le concept fonctionnel reste le parcours utilisateur connecté au Processus.
| Mode | Comportement | Cas courant |
|---|---|---|
| Redirection | Le participant ouvre l'URL du parcours dans la fenêtre du navigateur. | Onboarding, checkout, collecte de mandat. |
| Embarqué | Le parcours est présenté dans une zone intégrée lorsque le contexte et le contrat le permettent. | Portail opérateur ou espace client. |
La réponse reprend la même opération
Lorsqu'une Action utilisateur est complétée, ses sorties typées deviennent disponibles pour les
nodes suivants et la même instance de Processus reprend. La complétion émet
process.user_action.completed ; l'instance reste également consultable
par les surfaces d'observabilité et l'API.
Une redirection ou un acquittement d'interface ne prouve pas qu'un effet externe est réussi. Pour un paiement, une signature ou une vérification provider, utilisez le résultat ou l'événement métier documenté par l'intégration concernée.
Approbations et revue humaine restent des concepts distincts
Un Processus peut également attendre une décision humaine interne. Une
approval_request porte sa
propre politique d'agrégation, ses approval_assignment, son échéance et son résultat
terminal. Ce modèle ne doit pas être réduit à une simple Action utilisateur.
Le parcours du participant final peut afficher que l'opération attend une revue interne, mais l'autorité d'approbation vit dans la demande et ses assignments. Le canal qui distribue un lien d'approbation est séparé de la décision elle-même.