- Démarrage
- Meilleures pratiques
- Modélisation de l'organisation dans Orchestrator
- Meilleures pratiques d'automatisation
- Optimisation de l'infrastructure Unattended à l'aide de modèles de machine
- Organisation des ressources avec des balises
- Exportation des grilles dans l'arrière-plan
- Appliquer la gouvernance de la connexion Integration Service au niveau de l'utilisateur
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Paramètres
- Registre
- Cloud Robots
- Présentation des robots cloud
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Configurer une connexion ExpressRoute
- Diffusion en direct et contrôle à distance
- Robots Automation Suite
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
Guide de l'utilisateur d'Orchestrator
The Default Execution Identity feature reduces the setup required to run automations in a new Orchestrator tenant. Without this feature, deploying an automation to a new tenant typically fails with a "No unattended robot could be found" error because each folder requires a robot account and machine template before any job can run.
With Default Execution Identity, Orchestrator automatically provisions the required accounts and machines when a new tenant is registered, and applies a configurable default identity to every new root folder created in that tenant.
Mode de fonctionnement
Auto-provisioning on new tenant registration
When a new tenant is registered, Orchestrator automatically provisions:
- A default robot account with the Automation User role
- A Default Serverless machine template
This provisioning happens at tenant creation time and requires no admin intervention. Automations can run in a newly created tenant without any manual robot or machine setup.
Default Execution Identity tenant setting
Administrators can configure a Default Execution Identity in Tenant > Settings. The configuration specifies:
- One account, with the roles that account holds in each folder it is assigned to
- One machine template
- A flag controlling whether the assigned machine propagates to subfolders
At most one account and one machine can be specified in the configuration. A configuration referencing more than one account or more than one machine is rejected with a validation error.
Applying the identity to new root folders
When a new root folder is created, Orchestrator reads the Default Execution Identity configuration and automatically assigns the configured account and machine to that folder. Developers can deploy processes and run jobs immediately, without additional account or machine setup.
The default identity applies only to newly created root folders. Subfolders are not directly assigned; subfolder access follows the propagate-to-subfolders flag. Existing folders are not affected.
Scope and limitations
| Condition | Comportement |
|---|---|
| New tenant registration | A default robot account (Automation User role) and a Default Serverless machine template are automatically provisioned |
| Existing tenants | Auto-provisioning does not apply retroactively. Administrators must configure the Default Execution Identity setting manually. |
| New root folders | The configured account and machine are automatically assigned at folder creation |
| Existing folders | Not affected by the Default Execution Identity setting |
| Sous-dossiers | Not directly assigned. Access follows the propagate-to-subfolders flag. |
| Account limit | One account per Default Execution Identity configuration |
| Machine limit | One machine per Default Execution Identity configuration |
Cleanup behavior
When the account or machine referenced in the Default Execution Identity configuration is deleted, Orchestrator automatically removes that entry from the configuration. If the resulting configuration becomes empty, the apply-on-folder-creation path skips without raising an error.
If a referenced account or machine is missing at folder-creation time before the automatic cleanup runs, Orchestrator logs a warning and skips the assignment. Folder creation never fails because of a stale Default Execution Identity configuration.
Related task
To configure the Default Execution Identity setting, see Configure the Default Execution Identity.