Approbateurs dynamiques
Identifiez le bon approbateur depuis un utilisateur ou groupe Okta plutôt que d'intégrer un email figé dans chaque workflow.
“Qui doit approuver le renouvellement fournisseur Atlas ?”
Roster pour Okta
Transformez utilisateurs et groupes Okta en contexte de routage à l'exécution pour agents IA et workflows.
Roster se connecte à votre organisation Okta pour déterminer qui doit approuver, qui est responsable, qui doit effectuer la revue, recevoir ou prendre en charge le travail. Utilisez les utilisateurs et groupes Okta actuels comme socle organisationnel de la résolution de participants — sans coder en dur des noms dans les prompts, workflows ou logique applicative.
Dernière vérification : 13 juillet 2026
Votre annuaire sait qui sont les personnes. Roster détermine qui doit agir.
Okta fournit les utilisateurs, groupes, profils et données d'appartenance que votre organisation maintient déjà.
Mais un agent ou workflow demande rarement uniquement :
“Quels utilisateurs appartiennent à ce groupe ?”
Il demande :
“Qui doit approuver cette demande ?”
“Qui est responsable de cette escalade client ?”
“Qui est responsable de la revue sécurité ?”
“Qui doit agir lorsque le responsable habituel est indisponible ?”
Roster transforme les utilisateurs et groupes Okta sélectionnés en participants avec contexte projet, rôle, métadonnées et délégation — puis expose ce contexte aux agents IA, systèmes d'automatisation, pipelines CI et applications internes.
Comment Roster se connecte à Okta
Le connecteur Okta natif de Roster lit utilisateurs, groupes et appartenance directe via la Core API d'Okta.
Lorsqu'un administrateur cherche un utilisateur ou groupe Okta depuis Roster, le connecteur interroge Okta en direct.
Après que l'administrateur ait associé un enregistrement sélectionné à un participant Roster, Roster matérialise cet enregistrement pour la résolution de participants. Pour un groupe sélectionné, Roster stocke aussi les relations d'appartenance directe nécessaires à la résolution.
Roster ne synchronise pas l'intégralité des utilisateurs, groupes et appartenances de votre organisation Okta. Son worker rafraîchit les enregistrements et relations d'appartenance sélectionnés selon un planning configuré.
Ce que Roster permet d'identifier
Responsables de workflow
Mappez un groupe Okta à un participant Roster tel que Réviseur sécurité fournisseur, Propriétaire finance régional ou Approbateur de mise en production.
“Qui est responsable de la revue sécurité pour le projet Atlas ?”
Délégués actifs
Appliquez des délégations Roster limitées dans le temps lorsque le participant habituel est indisponible.
“Qui peut approuver pendant l'absence du propriétaire achats ?”
Contacts d'escalade
Identifiez l'utilisateur ou le groupe responsable d'un projet, client, région, processus ou niveau de risque particulier.
“Qui doit recevoir cette escalade client Enterprise ?”
Handoff agent-humain
Donnez aux agents IA un moyen fiable de sélectionner la bonne personne ou équipe lorsqu'un workflow requiert un jugement humain.
“Quel réviseur humain cet agent doit-il consulter avant d'exécuter l'action ?”
D'un groupe Okta à un participant de workflow
Un groupe Okta identifie un ensemble d'utilisateurs. Un participant Roster décrit la responsabilité métier que ces utilisateurs peuvent remplir.
Le même groupe Okta peut soutenir différentes responsabilités de workflow dans différents projets Roster, sans changer l'annuaire source.
Les participants Roster peuvent aussi porter des métadonnées métier telles que : Région, Service, Seuil d'approbation, Type de revue, Produit, Segment client, Niveau d'escalade.
Cela donne au moteur de résolution plus de contexte qu'une simple recherche d'annuaire.
Utilisez le contexte Okta depuis toutes les surfaces Roster
Une fois que des enregistrements Okta sont associés à des participants Roster, le même contexte organisationnel est disponible sur les surfaces d'intégration Roster.
MCP
Laissez Claude, ChatGPT, Codex ou un autre client MCP compatible poser des questions ouvertes de routage.
API REST
Ajoutez la résolution de participants aux applications internes, plateformes d'automatisation et environnements d'exécution d'agents personnalisés.
CLI et CI
Identifiez le responsable ou les validations requises depuis le terminal ou une pipeline CI.
Plateforme Roster
Laissez administrateurs et propriétaires de projet parcourir les enregistrements Okta, créer des participants, gérer les appartenances, configurer les délégations et consulter l'activité de résolution.
Ce que Roster lit depuis Okta
| Données Okta | Utilisé par Roster | Matérialisé dans Roster |
|---|---|---|
| ID utilisateur stable | Oui | Pour les utilisateurs et membres sélectionnés |
| Login utilisateur | Oui | Pour les enregistrements sélectionnés |
| Email utilisateur | Oui | Pour les enregistrements sélectionnés |
| Nom affiché | Oui | Pour les enregistrements sélectionnés |
| ID de groupe stable | Oui | Pour les groupes sélectionnés |
| Nom du groupe | Oui | Pour les groupes sélectionnés |
| Email du groupe, si présent | Oui | Pour les groupes sélectionnés |
| Membres directs du groupe | Oui | Pour les groupes sélectionnés |
| Mots de passe et authenticators | Non | Non |
| Applications et entitlements | Non | Non |
Roster normalise les enregistrements fournisseur sélectionnés dans sa propre représentation utilisateur et groupe d'annuaire tout en conservant leurs identifiants source Okta.
Le connecteur utilise actuellement ces chemins de ressources Okta Core API :
/api/v1/users
/api/v1/groups
/api/v1/groups/{id}/usersLe connecteur actuel de Roster est conçu pour lire les informations utilisateur, groupe et appartenance nécessaires à la résolution de participants. Il n'est pas utilisé pour administrer les utilisateurs ou groupes Okta.
Recherche en direct et résolution matérialisée
Roster utilise deux modes d'accès aux données délibérés.
Parcours du fournisseur en direct
Un administrateur peut chercher Okta en direct depuis le sélecteur de participants Roster. Cela permet de trouver des enregistrements qui n'ont pas encore été ajoutés à Roster.
Résolution matérialisée à l'exécution
Après sélection d'un enregistrement, Roster stocke la représentation d'annuaire requise pour la résolution de participants. Les recherches d'annuaire REST et MCP utilisent ces données Roster matérialisées plutôt que d'appeler Okta en direct à chaque requête d'agent ou workflow. Cela offre un dataset d'exécution cohérent sur l'API, le MCP, la CLI et la plateforme Roster.
Exigences de connexion
Pour configurer le connecteur d'annuaire Okta, vous aurez besoin de :
- 01L'URL de votre organisation Okta
- 02Un token API Okta
- 03Une variable d'environnement sécurisée ou une référence gestionnaire de secrets
- 04Un planning de rafraîchissement approprié
- 05Des identifiants utilisateur et groupe Okta stables
- 06Un accès en lecture suffisant aux utilisateurs, groupes et appartenances sélectionnés pour Roster
Le connecteur actuel utilise l'authentification par token API SSWS avec la Core API Okta.
Utilisez le rôle administrateur Okta au moindre privilège permettant au connecteur de lire les utilisateurs, groupes et informations d'appartenance requis. Appliquez les contrôles appropriés de propriété, rotation, expiration et révocation du token.
Exemple de référence de secret :
env:OKTA_API_TOKENGardez le token hors du code applicatif et du contrôle de source.
Votre annuaire Okta n'est pas votre configuration de connexion Roster
Roster prend en charge deux voies d'intégration Okta distinctes.
Connecteur d'annuaire Okta
Fournit utilisateurs, groupes et appartenance de groupe pour la résolution de participants.
Source d'annuaire Okta
Permet aux membres humains de se connecter à la plateforme Roster via Okta en OIDC — ou via une application SAML configurée indépendamment.
Ces intégrations peuvent être utilisées indépendamment ou ensemble. Configurer la connexion Okta ne rend pas automatiquement les enregistrements d'annuaire Okta disponibles au moteur de résolution. De même, configurer le connecteur d'annuaire n'active pas automatiquement la connexion Okta.
Conçu pour un déploiement entreprise contrôlé
Matérialisation sélective
Roster rafraîchit les utilisateurs, groupes et appartenances directes sélectionnés pour la résolution de participants plutôt que d'importer l'annuaire Okta complet.
Stockage de secrets externe
Le token API Okta peut rester dans l'environnement de déploiement ou le gestionnaire de secrets et être référencé par le connecteur Roster.
Rafraîchissement planifié
Le worker Roster met à jour les enregistrements d'annuaire sélectionnés et les relations d'appartenance en cache selon le planning configuré.
Provenance stable
Les enregistrements matérialisés conservent leurs informations sources propres au fournisseur et leurs identifiants Okta stables.
Accès Roster à portée limitée
Agents, comptes de service et applications ont toujours besoin des identifiants d'accès, autorisations et droits d'accès aux projets Roster appropriés avant de lire ou d'identifier des données de participants.
Exemple : identifier dynamiquement un approbateur achats
Une automatisation reçoit une demande de renouvellement fournisseur pour le projet Atlas. Le workflow connaît : le projet, la région du fournisseur, la valeur du contrat, l'action nécessitant une approbation. Il ne contient pas d'email d'approbateur figé.
À la place, il demande à Roster :
“Qui doit approuver le renouvellement fournisseur Atlas pour l'Europe à ce montant ?”
Roster évalue :
- le projet Atlas
- le participant achats pertinent
- les métadonnées du participant
- l'utilisateur ou groupe Okta associé
- l'appartenance matérialisée actuelle
- toute délégation Roster applicable
Le workflow reçoit le participant actif et poursuit avec son mécanisme existant de livraison d'approbation. Roster détermine qui doit recevoir la demande. Votre moteur de workflow reste responsable de l'envoi, de la collecte et de l'application de l'approbation.
Cas d'usage courants Okta et Roster
- Résoudre un approbateur depuis un groupe Okta
- Router les actions d'agent IA vers un réviseur humain
- Identifier le propriétaire d'un projet ou processus
- Résoudre la responsabilité régionale ou par service
- Appliquer une délégation temporaire pendant un congé
- Router les escalades client ou opérationnelles
- Déterminer le validation de mise en production ou de déploiement
- Remplacer les emails d'approbateurs statiques dans les workflows
- Donner aux clients MCP l'accès au contexte organisationnel
- Réutiliser la même logique de participants dans plusieurs applications