Roster pour n8n
Identifiez la bonne personne avant que le workflow ne route le travail.
Connectez n8n à l'API REST de Roster pour que vos workflows identifient approbateurs, responsables, réviseurs, contacts d'escalade et délégués à partir du contexte organisationnel courant.
n8n automatise le workflow. Roster détermine qui doit agir.
Dernière vérification : 14 juillet 2026
Les affectations statiques fragilisent les workflows dynamiques
n8n peut connecter des applications, transformer des données, exécuter des agents IA et automatiser des processus en plusieurs étapes.
Mais un workflow atteint souvent une question de routage à laquelle les données applicatives seules ne répondent pas :
“Qui doit approuver cet achat ?”
“Qui est responsable de ce client dans cette région ?”
“Qui doit réviser cette demande d'accès ?”
“Qui reçoit l'escalade après deux échecs ?”
“Qui remplace l'approbateur habituel ?”
Une adresse courriel fixe dans un nœud cesse d'être correcte dès que les responsabilités changent. De grandes tables de décision reproduisent la structure organisationnelle dans le workflow et deviennent difficiles à maintenir entre automatisations. Roster centralise le modèle de participants et permet à n8n d'obtenir la réponse à l'exécution.
Comment Roster s'intègre à un workflow n8n
Il s'agit d'une intégration API directe : n8n fournit le contexte du workflow, Roster retourne le participant identifié, et n8n exécute l'action suivante.
Déclencheur ou workflow n8n
↓
Nœud HTTP Request
↓
API REST Roster
↓
Projet + modèle de participants
↓
Utilisateurs, groupes, rôles, appartenances et délégations
↓
Participant identifié
↓
n8n route la tâche, le message, le ticket ou l'approbationCe que les workflows n8n peuvent identifier
Connecter Roster à n8n
Utilisez le nœud HTTP Request intégré de n8n pour appeler l'endpoint de résolution REST de Roster documenté pour votre déploiement.
- Créez une identité Roster pour le workflow avec accès aux projets et participants requis.
- Créez pour cette identité une clé API Roster à portée limitée.
- Stockez la clé dans les credentials n8n. Ne la placez ni dans les paramètres du nœud ni dans le JSON exporté du workflow.
- Configurez un nœud HTTP Request avec l'endpoint REST Roster et l'authentification Bearer.
- Envoyez une requête POST vers <your-roster-public-url>/api/v1/resolve avec Content-Type: application/json.
- Incluez query, et project_id lorsque le workflow doit résoudre dans un projet précis. Utilisez mode: "live" en production.
- Routez le workflow à partir de la réponse Resolve retournée par Roster.
- Ajoutez des branches distinctes pour not_found, out_of_scope, error, échec d'authentification, échec d'autorisation et indisponibilité du service.
Exemple de corps de requête :
{
"query": "Qui doit approuver cet achat logiciel de 75 000 CAD pour l'équipe des opérations canadiennes ?",
"project_id": "proj_123",
"mode": "live"
}La clé API requiert la portée api:resolve. Son accès effectif reste limité par les autorisations Roster de son propriétaire et les règles d'accès aux ressources.
Ce modèle convient pour :
- les workflows à fort volume ;
- les schémas de requête et de réponse strictement contrôlés ;
- les branches d'erreur prévisibles ;
- les workflows où la résolution des participants est toujours requise ;
- les workflows nécessitant une connexion actuellement vérifiée entre n8n et Roster.
Roster retourne un statut de résolution success, not_found, out_of_scope ou error. Les erreurs REST Roster suivent le format Problem Details de la RFC 9457 ; routez selon le statut HTTP et le champ stable type plutôt qu'un champ message historique.
Portée de résolution REST
Pour les automatisations limitées à resolve, gardez les portées étroites. L'accès effectif reste contraint par les autorisations Roster du propriétaire de la clé et les règles de ressources cibles.
api:resolveExemple : router une approbation d'achat
Un déclencheur Formulaire n8n reçoit une demande d'achat avec le montant, l'unité d'affaires, la région et le risque fournisseur.
“Qui doit approuver cet achat logiciel de 75 000 CAD pour l'équipe des opérations canadiennes ?”
- Le workflow prépare le contexte de résolution.
- Le nœud HTTP Request appelle l'API de résolution Roster avec le contexte du workflow :
POST <your-roster-public-url>/api/v1/resolve Authorization: Bearer $ROSTER_API_KEY Content-Type: application/json { "query": "Qui doit approuver cet achat logiciel de 75 000 CAD pour l'équipe des opérations canadiennes ?", "project_id": "proj_123", "mode": "live" } - Roster évalue le projet achats, le participant d'approbation, les métadonnées de seuil et de région, l'appartenance d'annuaire, le statut actif et les délégations.
- n8n utilise la réponse Resolve pour créer la tâche d'approbation.
- Une réponse not_found, out_of_scope, une erreur API ou une erreur d'autorisation suit une branche d'exception distincte.
Le workflow ne devine jamais l'affectataire, et chaque décision de routage est auditable via Requêtes Resolve, en parallèle de l'historique d'exécution n8n.
Roster complète n8n
n8n reste responsable des déclencheurs, intégrations, transformations, exécutions, nouvelles tentatives, notifications, approbations et mises à jour applicatives.
Roster fournit la décision organisationnelle nécessaire avant que le workflow ne sélectionne un participant humain. Il ne remplace ni la logique de workflow n8n, ni les credentials, ni les connecteurs applicatifs.