Quick Start Guide: New built-in groups and "add user" changes for UiPath Automation Cloud this week

In the next few days, we will release the new 'built-in groups" capability to our UiPath Automation Cloud for community. The same release will come to our enterprise cloud customers about a week later, per our normal rollout staging. This post walks you through some key changes, with a focus on how common operations change, and some new options the release brings you, as we don’t want these changes to unduly interrupt your operations.

We highly recommend that you read much more detail about these features in our docs here. This post is a “quick start” guide for existing administrators on updates to some common tasks, but there’s much more there. We hope you find this (and the product documentation) helpful! We’ll run through:

  • Where did my services, user and license tabs go in the new user experience?
  • How do I add a user to my organization and give them permissions on tenant Orchestrators now?
  • How do I use group to make managing default roles easier?
  • Configuring groups in Orchestrator in existing tenants
  • What are the default group permissions granted to new tenants?
  • My groups are configured! How do I add users to them?
  • Summary and Q&A

Where did my services, user and license tabs go?

We added a new left nav tab, and they’re now under the “Admin” section of the new left nav.

Over the next few months there will be more new services that need a home and we didn’t want to clutter up existing screens (like the home screen) and make them less useful. So watch for more services to arrive, just as our new UiPath AI Fabric service has appeared now (this blog is not about AI Fabric, but this one is, if you’d like to know more about that!). Please note that not all plans have access to all services, and in a future release we will show only those plans that you have access to.

In the meantime, the tabs under “Admin” will look startlingly familiar, and the home screen remains the “summary” page of your entire Automation Cloud environment:

How do I add an individual user and grant them permissions on tenant Orchestrators now?

Previously, to assign permissions and mange users, you needed to be an org admin and go back and forth between the portal and the orchestrator UI. No more! Now, you add a new user to the organization once in the portal, then add and manage them at the tenant level entirely within Orchestrator. You can add an org user to as many tenants are you wish, or none at all - and you can still add multiple new users at once to the organization.

Here’s how:

  1. Invite the user to the organization, if they are not an existing user.

You must be an org admin or owner to add a new user. The invitation dialog now includes the option to add invited users to groups. If you do not want to use groups, do not check any of the group boxes (the ‘everyone’ group is selected by default, but does not assign any permissions in tenant Orchestrators, so that’s OK).

Note that if you do check one or more group boxes (except ‘everyone’), you will be assigning the user some default permissions in any new tenants. So if in doubt, leave them blank for now. When you have configured groups as you want them (see sections below), you can add users to them later, and change your user management process to leverage them correctly.

You will step through the following screens:


Invite New User 2
Invite New User 3

As the dialog says, you have successfully invited the new user. Click “Go to Services” in the dialog, and you’re ready for step 2!

  1. Add an organization user (or invitee) to one or more tenant Orchestrators.

You need to be an Orchestrator administrator on the tenant, or an org admin/owner to do this. Note that this means you can now create an administrator with the scope to control existing users within a tenant’s Orchestrator without giving them the right to add new users to the organization.

If you clicked “Go to Services” after adding a new user to the org, you’ll be on the Admin/Services page already. If you are adding an existing user, go there now.

Click on the manage users button beside the tenant you want to add the user to.

First, in ‘users‘ click the + button in the users window, then select ‘add user or group’

Add the user, optionally adding automatic robot provisioning if you wish


Click ‘add’ and the org user is now also a user of the tenant orchestrator. Either the orchestrator admin on this tenant or the org admin can now manage them within the tenant, as they did previously.

You can use the “Manage users in other services” link at the top right to quickly go back to the services list in the portal, and then add the user to other tenants if desired, potentially with different roles. For example, a user could be an Orchestrator administrator in one tenant but not have administrator permissions in another.

How do I use groups to make managing default roles easier?

First, some things to know about the new groups

  1. Group membership is at the organization level. You don’t have to add users to groups. But, if you do, you are granting them some default, role-based permissions in Orchestrator for all new tenants (see 2 and 3). Adding a user to a group gives them whatever permissions that group has assigned in each tenant’s Orchestrator.

  2. Group permissions in each tenant’s Orchestrator are set (and behave) just like user permissions. You can work with groups everywhere you can work with users at the tenant/Orchestrator level, and any users added to a group at the org level will behave according the group’s permissions in each tenant.

  3. Default permissions are granted for each group (except everyone) in Orchestrator in new tenants. Orchestrator in new tenants (created after the groups feature goes live) will have default permissions assigned for members of each group except the everyone group, which never has any default permissions assigned (you can assign some if you want to use it)

  4. Default permissions are not granted for any group in existing tenants. For predictability, we don’t assign groups any permissions in your existing tenants. Therefore, adding users to groups will not give them permissions in existing tenants – unless you explicitly add those permissions to Orchestrator in one or more existing tenants.

  5. You have control. You can configure or modify tenant-level and folder-level permissions (through roles) granted to members of any group in any tenant’s Orchestrator at any time. That means that permissions assigned to a group in one tenant need not be the same permissions assigned to it in another tenant. You can choose to standardize how groups are applied across all tenants, or grant permissions only to individual users (no groups) in specific tenants and use groups in others.

Configuring groups in Orchestrator in existing tenants

As mentioned, no permissions are granted to groups in your existing tenants. If you want to change that to take advantage of groups in existing tenants, you can.

The simple rule is, wherever you can add or grant permissions to a user in a tenant’s Orchestrator, you can add or grant permissions to a group. The UX is even the same for both. When you add a group, any org users who are members of that group get those permissions in that tenant’s Orchestrator

So, to grant permissions to the ‘Automation Users’ group in an existing tenant, treat it exactly like a user from within the tenant Orchestrator:

In Users, click the ‘+’ then “Add user or group”. This time, we are going to add a group.

In the ‘add user or group’ dialog, search for the group name instead of the user name. Both user and group names are shown in the search results by default (you can filter between them):

Grant the group role permissions just as you would a user, click add, and you’re done!

In this case, the group automation users has now been granted the ‘Automation User’ role in this tenant only . So any user added to the Automation Users group at the organization level will get that permission in this tenant.

What are the default permissions granted to new tenants?

If you have existing modern folders, you can of course replicate this exact taxonomy so that users added to a group behave the same in every tenant. Conversely, you can remove or modify these default group permissions in particular new tenants when you create them if you wish.

For example, you may create a new tenant for test and not want the “automation users” group to see the processes being tested. Therefore, you would either modify the permissions in your test tenant Orchestrator for that group or (more likely) simply remove the group altogether from the users section, and assign the Automation User role to individual users in the test group.

Again, if you are ever unsure where to manage group permissions, it is always in the same place as you manage individual users. So to remove (or, less dramatically, deactivate) an entire group from an individual tenant Orchestrator, you would go to users in Orchestrator.

My groups are configured! How do I add users to them?

This is the easy part (which is good, because it’s the part you will probably want to do all the time – group configuration is typically a “once per tenant” affair)

Option 1: Select a group for the user when you invite them. Upon accepting the invitation, the user will be granted permissions in each tenant’s Orchestrator according to how you set the permissions for the group in that Orchestrator.

Reminder: you cannot uncheck the “Everyone” group, but it never grants default permissions in either existing or new tenants (as you can see in the screenshot above). It is available for your use, should you wish to give everyone a set of default permissions in one or more tenants.

add groups at invitiation

Option 2: Add (or remove) existing users from a group, with the ‘edit’ icon in the users tab of the admin section of the portal.

Summary

With these changes, we have more formally separated the organizational directory of users and groups from how permissions are applied in services (like Orchestrator) at the tenant level.

Groups make it easier to manage users across multiple tenants and services, without having to configure permissions for each individual user – but you always have the option to do that.

For smaller customers, we hope this capability will simplify management in the UiPath Automation Cloud, even thought it involves some initial change to how things are done at rollout. In this future, as we add more services, this model is scalable, so it will simplify how you manage services beyond Orchestrator in each tenant, too,

For larger customers who may have more complex group needs, this is a stepping stone to rolling out full Azure Active Directory user and group integration in the next few months, where you will be able to work with AAD groups in each tenant/service the same way that, with this release, you can work with the built-on groups.

We hope you’re excited about the changes, find them useful, and thank you for being a UiPath customer.

Q&A

Q: If I add a user to a group, and then grant them individual permissions, which do they get?

A: The union of all permissions, the ones added explicitly to the user and the ones based on group membership.

Q: Can I go on managing individuals without using groups at all?

A: Absolutely. Just don’t add users to any groups! Be aware that new tenants will get default permissions granted for each group except “everyone”, so if you want to be doubly sure, you may want to deactivate or remove them. But as long as you don’t add any users to groups, they have no impact.

Q: Can I add more than 4 groups?

A: Sorry, not at present. You can configure what the 4 groups do however you like on each tenant, but you can’t add to them or rename them right now.

Q: Can a tenant Orchestrator admin add someone to that tenant who is not in the org user list in the portal?

A: No. All users must be invited to the organization by an org admin, and then Orchestrator administrators in each tenant can add them to, and grant them permissions on, individual tenants.

10 Likes

Looks good with groups!

One thing I miss (or haven’t been able to find) is the ability to prevent a user from seeing “licenses”, “users” and “API Keys”.
It isn’t very sensitive data but it would be great if we with a role have the opportunity to limit these things as well, business users don’t need access to that information, especially not API key.

PS
I already posted this question HERE but then I saw this post and I think it fits better here.

Any idea of when will we be able to create custom groups? More than their usage in the role management, I’m more interested in the access to modern folders management