While multi-tenancy is important and necessary for Orchestrator, it makes less sense for other components such as:
Integration Service
Automation Hub
Insights
The use case here would be to support a more organization centric view of common shared elements that span multiple tenants but can be controlled by RBAC at the tenant level.
For example, I want to have a single point of entry for Automation Ideas throughout the organization irrespective of the tenant. This means a single Automation Hub. Ideas through the intake process can be aligned to specific tenants, such as Ideas that come in from Europe can be aligned to a Europe tenant, etc.
RBAC can be in place whereby once an Idea is aligned to a tenant, only users on that tenant can see those ideas. Or an option where you can align an idea to a tenant but allow for global organization visibility.
The same can be said about Insights. At an organization level, I want to be able to see insights as an aggregate from all tenants if I have the right RBAC to do so. Otherwise, RBAC can be created within Insights to be able to allow only specific tenant users to see Insight data for their tenant.
Integration services would be the same. Organizational wide we may want to have standard connectors that anyone can use irrespective of tenant, and there may need to be some connectors that are RBAC’ed to specific tenants.
The services you mentioned are scoped at tenant level to ensure data sovereignty per customer’s needs. Each service product manager has the option to put into balance whether they want the service to be org scoped or tenant scoped, and based on the pros & cons, a decision was made.
For Insights, there is a cross-tenant reporting capability that addresses the need.
For Automation Hub, your scenario can be easily covered by enabling the Automation Hub service at a tenant called “Global”, an make sure all users have access in the Automation Hub service hosted in that tenant (you can use user group assignation for this).
In conclusion, while I understand the need, there are ways to address it already. And the decision for each service was taken by having more benefits than cons for the selected choice.
I’ll reach out to our UiPath team to inquire further about both capabilities you mentioned.
How does creating a “Global” tenant allow Automation Hub to be the single point of entry? Would it be that once an idea is progressed, it would be “exported” to Automation Hub within the tenant that the automation would eventually run via Orchestrator to then be able to close the loop with all of the Insights capabilities?
Thank you for the additional question.
I think this touches on a more in-depth aspect related to how did you separate the access in Orchestrator between:
having Orchestrator enabled within several tenants vs having Orchestrator enabled within just 1 tenant, but use the folders to further separate the access for various functional areas.
Because if we say that 1 idea in Automation Hub get developed into an automation project and ultimately it gets published into N Orchestrators enabled on various tenants, then there is no possibility to connect that 1 idea to the n packages deployed on the n Orchestrators (AH connects only to the services enabled within the same tenant, not cross-tenant).
On the other hand, if you go with 1 Orchestrator and using separate folders for separating access to the automations, then having 1 tenant Global, on which you enabled AH & Orchestrator & Insights, will allow starting with 1 idea in AH, building an automation, deploying the package in OR, creating a process in either a Shared folder of separate processes in different folders, and ultimately seeing the data flowing in Insights.
As mentioned, the decision to have a service organization level scoped or tenant level scoped is based on weighting the pros & cons for each option. And in the case of Automation Hub, being tenant level covers better the reality of the partners and large customers, which want more control in managing the access to services.
Hope this brings a bit of clarity. Of course, we are open to feedback.
Thank you!
For example, I want to have a single point of entry for Automation Ideas throughout the organization irrespective of the tenant. This means a single Automation Hub. Ideas through the intake process can be aligned to specific tenants, such as Ideas that come in from Europe can be aligned to a Europe tenant, etc.
The importance here is that by moving Automation Hub to the Organization, it can be a central landing point for the entire organization.
Part 2 of this request would be to create APIs for Insights (since I’m assuming it’s backend by Elastic), so that any automation tool within the Enterprise can publish process/robot related information that can be displayed in Insights.
The value here is the recognition that most organizations will have more than one automation tool and this positions UiPath to be able to both be the common place to raise and look at Idea’s, but also have a single-pane-of-glass for Reporting and ROI.
Your Integration Service is currently unusable in a multi tenant setup where you have a development and production tenant.
This is because the connection in the workflow is hard coded to a guid on your development tenant meaning that the same code cannot run on the production tenant since that same connection guid doesn’t exist.
This is a rather gross oversight in my opion and something we urgently need correcting to actually use the integrations, I personally don’t advocate for an organizational level connection / integration service, I think its great that its defined on tenant level, but you need to update your activities so that we can connect my connection name so we can harmonize across tenants or allow us to use the same ID accross tenants.
