- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Managing Folders
- Organizing Folders
- Personal Workspaces
- Managing Personal Workspaces
- Audit
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Personal Workspaces
A personal workspace is a folder available for the dedicated use of a particular attended user. You can enable creating a personal workspace for the accounts and groups to which you wish to grant robot access using attended robots. If enabled, this workspace is automatically created when the user is provisioned in Orchestrator.
Personal workspaces come with their own dedicated package feed by default, meaning packages are kept separate and only available in the specific workspace they have been published to. Any package that is added to the workspace gets automatically deployed as a process in the workspace.
Packages stored in a user's personal workspace exist outside of the main Orchestrator feed and thus are not visible or accessible by other users. For each package uploaded, a corresponding process is automatically created (or updated in the case of existing packages and processes), enabling the user to launch their automation almost instantly after publication, with no Orchestrator access or actions needed.
- Starting a job in a personal workspace with its own package feed is only supported for 2020.10+ Robots.
- If the package contains trigger activities, the corresponding queue or time trigger is automatically created in your personal workspace.
- Make sure you create the queue referenced by the queue trigger prior to publishing the package from Studio.
To accommodate trigger-based automations from Studio, personal workspaces functionality has been adjusted as follows:
- Publishing a project to Orchestrator makes the package available in your personal workspace and automatically creates a process in the workspace. The process has the same name as the Studio project.
-
Republishing the automation project to Orchestrator overwrites the queue trigger properties set by the activity.
For example, if you manually edit a trigger in Orchestrator and set an alert option, this setting will be preserved at republishing. However, a time trigger Cron expression or a queue trigger SLA prediction is overwritten by the value present in the Studio project.
-
At publish time, Orchestrator chooses from the available personal workspace runtimes to execute the job. The runtime precedence is the following:
- Production (Unattended)
- Nonproduction
For example, if no Production runtimes exist in your personal workspace, Orchestrator uses an available NonProduction runtime. If none exists, the job fails.
If the selected runtime becomes unavailable between job executions, the upcoming job execution fails, since Orchestrator does not look for the next available one.
Orchestrator automatically manages machine templates for personal workspace owners. A machine template with a Studio runtime is automatically created and assigned to each new personal workspace. This removes unnecessary overhead from the developer, who can begin working in the context of that workspace right away. That includes publishing automation projects and launching jobs from Orchestrator for debugging purposes.
Users that work in other folders besides their personal workspace can benefit from the Orchestrator debugging capabilities of their machine template by assigning it to the folders they are working in (i.e., the folders they have been assigned to).
- Packages / Processes
- Jobs
- Assets
- Logs
- Queues and Queue Items
- Storage Buckets (if the functionality is enabled at the tenant level)
Users with administrator privileges can handle all personal workspaces in a tenant from the Personal Workspaces page. On this page, an admin can check the last login time of the workspace's owner and can perform several operations:
- See usage - shows an overview of the entities and running/pending jobs in the workspace.
- Convert them into folders - converts the workspace into a folder with its own package feed while creating a blank workspace as a replacement for the initial one.
- Exploring their contents - allows for accessing the contents of the personal workspace and executing jobs in the context of the workspace. The original owner of the personal workspace is properly notified whenever a user begins or ends an exploratory session.
- Deleting them
- Active - The owner is an active Orchestrator user.
- Inactive - The owner is not an active Orchestrator user i.e. has been deactivated.
- Orphaned - The owner no longer exists as a user in Orchestrator.
Where from: Tenant Context > Folders > Personal Workspaces tab
See Managing Personal Workspaces for details.
You can enable personal workspace creation for an account or group when creating or editing the account/group on the Manage Access page.
Where from: Tenant > Manage Access
You can mass enable personal workspaces for all accounts that use a certain attended licensing profile irrespective of their group membership.
Where from: Tenant > Settings > General > Personal Workspaces
UI profiles allow you to control the level of detail of the Orchestrator UI for users with personal workspaces. There are two options available:
-
Standard Interface - Users see all folders in a tenant, the default Orchestrator menus, and can select their personal workspace from the folder picker.
-
Personal Workspace - Users see a modified UI showing the contents of their personal workspace and no side-menu.
Note: You cannot change the UI profile for yourself as a means to prevent accidental disabling of core functionality.
Tenant-level permissions required to manage the workspaces of other users:
- Settings - View and Settings - Edit to allow the use of personal workspaces in the tenant from the Tenant > Settings page.
- Users - View and Users - Edit to enable a personal workspace for a user or group by editing it from the Manage Access page.
Folder-level permissions required to use a personal workspace:
- Alerts - View to see alerts generated for the personal workspace.
- Actions - View,Actions - Edit,Actions - Create, and Actions - Delete to enable long-running workflow execution in the personal workspace.
- Action Catalogs - View,Action Catalogs - Edit,Action Catalogs - Create,Action Catalogs - Delete to allow the user to manage action catalogs in the personal workspace.
