- Getting started
- Best practices
- Organization Modeling in Orchestrator
- Managing Large Deployments
- Automation Best Practices
- Tenant
- Actions
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Action Catalogs
- Profile
- System Administrator
- Identity Server
- Authentication
- Other Configurations
- Integrations
- Classic Robots
- Troubleshooting
Organization Modeling in Orchestrator
Orchestrator provides multiple features which can be used in modeling your deployment to provide easy and efficient administration while also ensuring proper asset isolation and access control across your organization, regardless of size or structure.
A single Orchestrator instance can be split into multiple Tenants, with each tenant being entirely isolated from any others. No automations, resources, or users are shared or accessible across different tenants.
Each tenant can then be further subdivided and organized into Folders. You can create as many classic or modern folders as needed to accomplish your desired structure. Each type of folder has different features and capabilities, enabling you to use the appropriate type for the way in which you want to manage the administration and sharing of automations across your organization.
Tenants are designed for the purpose of complete isolation of all Orchestrator entities (i.e., Robots, Assets, Queues, etc.) between these segregated instances of your deployment, all without having to maintain multiple Orchestrators. Some examples of separating your Orchestrator into tenants:
- A tenant for each regional or international office of your enterprise, as users from each region have automations specific for the applicable laws and procedures of that region (e.g., HR processes in the USA vs. Europe or Japan).
- Maintaining multiple development and testing environments.
- Isolating sensitive data, such as payroll processes or confidential projects.
Tenants are thus best used in situations where you want all users, resources, and settings of your automation solutions to be managed independently by designated tenant administrators.
Modern folders provide multiple features not available in the context of classic folders, such as automatic robot management, hierarchical structures, and fine grained role assignment for users. See here for more details.
The guiding purpose of modern folders is the simplified management of large deployments by enabling the sharing of automations across different departments, integration with your existing AD groups, and expanded control over user permissions and robot creation.
For example, you can create a separate folder for your Finance and HR departments, adding those respective groups from your company Active Directory to their corresponding folder, while also allowing your HR users to have access to the Expense Report automations contained in the Finance folder rather than having to recreate for each separate user or group in your enterprise.
Classic folders function in the same manner as previous Orchestrator versions, preserving full backwards compatibility during the transition to the modern model. See here for a comparison of the two folder types.
Beyond maintaining this backward compatibility for existing deployments, classic folders are useful in providing segregation of automations in less complex deployments where separation by tenant is not needed. In classic folders, user permissions are set at the tenant level with no folder-specific roles available. Users also have access to automations only in those folders to which they are assigned.
Given this added complexity, classic folders are best used for deployments with smaller numbers of robots and administrators.
