A repository is a centralized location for storing and managing automations and their supporting assets. It facilitates organization of resources for easy access and reuse.

Key features

  • Centralized storage: Provides a single location for storing all automations, scripts, and related resources ensuring easy access for teams working together on automation projects.
  • Version control: Tracks changes made to automations over time, enabling users to revert to previous versions if necessary. It helps maintain a history of updates and modifications.
  • Collaboration: Enables multiple users (teams) to work on automations, ensuring they have access to the latest versions of automations.
  • Security and access control: Provides role-based access control (RBAC) to restrict unauthorized access, thus maintaining secure storage of sensitive data in the automations.
  • Reuse: Promotes reuse of existing automations or supporting files to reduce development time and enables users to leverage pre-built automations as templates.
  • Backup and recovery: Enables integration with external Git repositories to prevent data loss. If a user account is accidentally deleted, this helps recover automations stored in that user's private repository.

Types of repositories

The automations along with their dependencies are listed within a selected folder in the Public and Private repositories. Depending on the license, users logging in to the Control Room can access the following repositories:

Public repository
The public repository is the global (server) repository that serves as a centralized location for storing the latest versions of automations and associated files. It maintains updated automation files and acts as a shared workspace where automations can be executed.

Access to the public repository is managed through RBAC. Users such as Professional Developers, Citizen Developers, administrators, and Bot Runners can interact with the public repository based on their assigned roles and permissions.

Automations created by Professional Developers and Citizen Developers can be selectively shared with specific Bot Runner users in the public repository by defining folder or file-level permissions. To do this, developers must first check in the automation from their private repository to the public repository, ensuring proper access control.

Private repository
The private repository is a user-specific repository on the server, designed to create and manage a user's workspace in a shared environment. This repository is primarily used to create and test automations, enabling users to view and manage all their activities in one centralized location. Automations in the private repository are only accessible to the users who created them.

Automation files remain in the private (local) repository until they are checked in. Upon successful check-in, the files are moved to the public (global) repository. If an automation is checked out from the public repository for modification and checked in again, a new version is created in the public repository, maintaining version history.

When an automation is created in the private repository, the automation name must be unique. If an automation or folder with the same name exists in the public repository (in the same folder location accessible to the user), the user cannot create, check out, or rename an automation with the same name in their private repository.

Users with administrative privileges or a Bot Runner license do not have access to the private repository, as they are not responsible for creating automations.

External Git repository

Git integration with the Control Room ensures a one-to-one mapping between the automations checked in to the public workspace of the Control Room and the remote Git repository structure. Git commits enforce security, compliance, and code standards, ensuring that organizational best practices are consistently applied to automation development processes. By exposing files to the remote Git host, users can review automation code and files using third-party comparison, helping to maintain compliance and security standards.

When a user checks in an automation from the private repository to the public repository, the folder structure and dependent files are also checked in or created in the public repository if they do not already exist. The automation file is then deleted from the private repository. If an external Git repository is configured, the files are committed and pushed to the remote Git repository after a successful check-in.

The Control Room can be configured to replicate its built-in Git repository with a remote Git host, synchronizing information through Git pushes. The following sources are certified for Git integration with the Control Room:

  • GitHub
  • Bitbucket
  • Azure DevOps
  • GitLab

Folder structure

The folder structure in the Control Room is designed to organize and manage automation assets efficiently. The Control Room utilizes a hierarchical folder structure to store and organize automations, scripts, and related files. The folders in the public and private repositories help manage the automation resources.

The folder hierarchy consists of the following:

  • Root folder: The top level of the folder structure in both public and private repositories. It contains all parent and subfolders.
  • Parent folders: Automation files categorized by individual project of function. The parent folders can have multiple levels of subfolders for more granular organization.
  • Subfolders: Enables creation of nested structures to organize an automation and supporting files within parent folders.

For example, automations can be organized by departments and their respective subdepartments. A parent folder can be named Finance with subfolders such as Accounts payable, Accounts receivable, and Expense reports.

The Bot folder is the default folder available in the Control Room. Folder permissions can be applied at root, parent, or subfolder levels to ensure secure and controlled access.
Note: The Bot Store folder can be made available to users with appropriate permissions.

The Files and folders table lists details such as automation type, name, folder path, automation status, the platform where the automation was created (Windows or macOS), and the source or version of the automation. You can search or filter automations and files by automation type, name, status, or platform.

The Search within subfolders is an advanced search option to search and locate bots, files, processes, and forms within a folder and its subfolders from your public and private workspaces. With this option enabled, a new column, Folder path displays the location of the folder and subfolders for the bot.

Repository guidelines

Ensure a well-organized, efficient, and secure repository structure that supports efficient automation development, testing, and deployment processes by following these guideline.

  • Use meaningful names for folders to make automation files easier to find.
  • Structure the repository to reflect the organization's departments or function and group related automations accordingly.
  • Keep the number of subfolders within a folder to a maximum of 30 to make the repository easier to manage and navigate.
  • Regularly review and archive unused files to maintain an organized structure.
  • Define clear access permissions to protect sensitive data and ensure collaboration.
  • Use separate Control Room instances for development, test, and production environments.
  • Use the public repository for deployment only and not to store automation files.
  • Integrate external Git for version history and backup.