The concept of assigning permissions is often confusing and sometimes cumbersome for those just starting off.

I bet most of you haven’t even seen the permissions and roles page, and are probably scratching your heads wondering what it’s all about.

Learning how to work with it is no easy task either, since only the Enterprise Edition has it, so there is little to no opportunity for us explore and experiment.

And its not like the client will simply hand it over.

But before we dive into any of that, why come up with this system in the first place?

What good has segregating people ever brought us?

Wasn’t it one man’s dream, that we would one day live in a nation where we won’t be judged by the access granted to us, but by the quality of our development?

Why are Permissions assigned to Users?

Permissions are never “assigned” to Users.

What’s the Point in Having Permissions if You Can’t “Assign” Them to Anyone?

No no, you’ve got it all wrong.

Permissions aren’t assigned to Users, because they are assigned to Roles and its these Roles that are mapped to Users.

Thats Two Times the Effort!

Not quite.

Structuring the system like so actually saves time.

Think about it, say you had around hundred users using the Control Room.

You’d have to assign permissions to all hundred users, which would take forever.

This is avoided, by introducing Roles.

Instead of assigning permissions to each user, you can instead assign permissions to a Role which is then mapped to a User.

Roles and Permissions

Lucky for us, Automation Anywhere has a set of predefined roles or system roles, so we won’t have a tough time trying to figure out what to assign to whom.

But there are times when you have to be as restrictive as you possibly can.

Maybe you’d like Bot_Creator_TCT to stick with bot development and nothing more.

Your gut is telling you that he might be using it as material for that silly blog of his. I can assure you that he isn’t doing anything of the sort, and that your gut is simply lying to you.

Using Roles, we may impose restrictions which will prevent Bot_Creator_TCT from blogging about your Salesforce credentials.

The Roles and Permissions being explored here are those which I believe are important. I could be dead wrong since I’m still in the process of learning, so please don’t shoot me.

Let’s look at a couple of predefined roles, before heading over into permissions.

I’ve decided to introduce some “characters” just to make it easier for you to remember. Think of this as a little experiment of mine.

If you want to explore all predefined roles, then visit this link.

Predefine Roles (The Ones I Think are Important)

AAE_Admin

Meet your Queen.

She is the all-seeing, all-knowing and all-accessing entity, with the power to bestow permissions onto others.

She creates Users in her own image, but with lesser permissions. We can’t have too many Admins running about now can we?

Well actually we can, but it doesn’t make sense to have more administrators with access to everything in the Control Room, instead it would make sense to introduce a handful of Lords with dominion over select territories, like Credential Vaults, device pools, queues, you get the point.

AAE_Locker Admin

This is the Hagrid of the Control Room.

He can access any credential and Locker, regardless of who owns it. In a way, he owns the owner and can change the owner if needed.

How Will He Log into Salesforce without Credentials?

The Credential Vault has its own levels permissions which require either the owner (who created the locker) or Hagrid to intervene. The AAE_Admin can also play a part in this if she wants to.

If you want Bot_Creator_TCT to use the Credentials, but not view or edit it, then add him as Consumer.

If you want Bot_Creator_TCT to handle your Credentials, then you have to add him as Participant.

If you wish to transfer ownership over to Bot_Creator_TCT, that can only be performed by Hagrid or AAE_Admin.

Hagrid might ask whether it’s a good idea to trust Bot_Creator_TCT with sensitive data, to which you will respond “Absolutely, I trust him with my heart and soul.”

AAE_Pool Admin

This is the Lifeguard of the Control Room.

It’s thanks to him that you have a massive Bot pool where you can safely deploy your Automation into, otherwise you’d have to deploy them in the kiddie pool back home.

A single Bot Runner will suffice if it’s a small Automation, but what if you had several Automations?

Can’t let them into the same kiddie pool, now can you?

AAE_Queue Admin

If you have an automation that takes forever to complete because it has to process thousands or records, you can call in the Queue Masterchef.

He trims your automation time short by chopping them up into even segments before dropping them into the bot pool and cooking it to finesse.

AAE_Basic

This is your average Joe.

Almost everyone has an average Joe inside of them, waiting for you to let your guard down and…well he just keeps waiting.

He is an average Joe.

He does the bare minimum, like pushing papers into various Folder before logging off for the day with a root beer in hand.

His hobbies include showing up late to work, and leaving early.

Before We Proceed

You don’t have to create custom roles for every user you create.

By default, all users are Average Joes, and it’s up to you whether to promote them or not.

If you need someone to manage the Lockers, then simply assign one of the users with AAE_LockerAdmin Role. If there aren’t too many users in the Control Room, then it would make sense for the AAE_Admin to take care of all administrative work.

However, it is better to have custom roles since you have more options to restrict access, but to create Custom Roles, you have to be intimately aware of the Permissions available in the Control Room and what collection of permissions are required for the user you are customizing it for to operate without running into anything he or she isn’t supposed to.

In addition to Permissions, there is an additional level of permissions for the Bots themselves.

For example, a user can only run Bots developed by Bot_Creator_TCT if he has permission to Run them from this permissions section which we will visit in a moment.

Common Permissions (IMO)

All permissions under Bots are important.

You (Yes you) have to be intimately aware of what permissions enable you to develop, run, and push bots.

You should be able to View and Run Bots.

Now I know what you are thinking.

What All Permissions Do I Require to Build Bots?

There aren’t any permissions which will grant you the necessary privilege to build bot.

You need a license for that.

Wait, So that Means…

Yes, you are absolutely right.

Its time for another meme.

Uhh…That Isn’t What I Was About To Say.

Moving on, you should also be able to Create and Rename Folders.

What is the point in creating bots if you can’t arrange them into folders?

If you are smart about developing automations (like I am wink* wink*), then you will divide your automation into segments which can be reused, as opposed to developing a thousand line workflow which can be thrown out of the window.

Then there is the option of Importing and Exporting bots. It isn’t necessary to provide these permission either, since developers don’t have to download automation unless you want them to keep few of them in a local repository for version control.

Devices

Now that you have everything that you will ever need to develop bots…oh wait you don’t.

Sure, you might be developing workflows in the Control Room, but you have to test them out right?

You can’t run automations on your device unless you register it to the Control Room first, and you won’t be able to do that either unless you have “Register device” checked under Devices.

Schedule Bots

What good are automations, if you can’t schedule them?

If it’s only a handful of bots, they can be manually triggered, but what if there are over 50 bots in the Control Room?

No one is going to keep track of all 50 bots, so it makes sense to introduce a functionality to schedule automations.

But Wait, There’s More

Remember that additional permission section I was talking about earlier?

Once you head over to Bots, you can restrict permissions to the Bots for that particular role.

What that means, is you can decide whether people mapped to that particular role can run, schedule, Check In, Check out, Clone or Delete bots.

If you’d like to view the entire list of permissions, you can visit it here. The permissions related to Bots can be found here.

In Conclusion

When a company invests in RPA, they aren’t just looking at one or two processes. Once the bots they invest into start providing massive returns (which it does), it encourages them to search for more opportunities.

RBAC simply lets us manage users, bots, sensitive data, and ensure nothing goes wrong within the Control Room.

There is a lot more to be explored here, like IQ Bot, Bot Insights, AARI or Discovery Bot permissions but I am not going to do that because the article is already bloated up.

Maybe the burrito had something to do with it…