So let's talk about Role-based access control. So who can run what automation, on what inventory, with what credentials, becomes increasingly important as you scale up automation and enterprise. So we can group, teams or users into 3 different groups. So we'll kind of explain on the next slide and what that means? And these rights can be assigned across all different objects. So this user could have access to this credential, but not that job template. Or this team has access to this particular inventory, but not that inventory. And all of this can be backed by enterprise authentication if needed. Meaning that these teams could be imported from like an LDAP or Azure Active Directory or whatever you happen to be using within your organization.

So the 3 kind of levels we have with an automation platform or organization, which is unfortunate sometimes to me because I kind of refer to like a business unit within a company isn't an organization. Sometimes I have to clarify if I'm meaning more of the abstract term organization or the specific term within automation controller. An organization is a just a logical collection of users. It's just the highest level grouping we have within Ansible Automation Platform. We then have teams. It is almost but teams in our organizations, except teams are not required. They allow you to sub-divide an organization, but they're not actually required. You could put users directly into an organization, but you don't need to necessarily have a team. It just allows you to sub-divide the organization. And then obviously the lowest one is a user. These users can have different roles.

So I can have a user that is like an admin user or just a normal user that we assigned to a group and then they inherit the, the role-based access control that, particular team or that organization. So it's a lot to take in. So again, let's move into a practical example and I will show what this looks like on automation controller. There's going to be fairly a simple exercise here is we're going to make, I have a bunch of users in here, but we'll make it a user. So make a user we'll make him, Jim, I'll make it really simple. No particular reason I chose Jim. I just thought it would be a good one. Nameless. Jim. The password, we need a password. I'll just make it a password because that's super cool. We'll make this Default. And this is a Normal User. And I need the password can match or would be red. We'll click Save. So don't want my last past credential management.

So in here I'm going to take a random job, maybe one of the ones we just made. So we'll show the Apache job. And we're going to give access to Jim. You can see all those users are loaded in here and we can search. So we're going to give them the ability we have kind of a breakdown of Read. And it can just look at it. Admin, it can manage all aspects, meaning they can edit that job template and change it, or they can just execute it. So we'll just go ahead and say that Execute it. So this user jim, can execute it. So we're going to log out. We're going to login as jim and you'll see that jim shows up in the top, User Details. And we look at Templates, there's only one Job Template now. And if I click on that Job Template, I don't have an edit option. I can see who can access it. I can add Schedules, which we haven't talked about, but that's just saying like when we could run a job.

So you could run it every hour or every every day or once a month? I can see when that Job run, I can view the Surveys if there happened to be one. But I can't make templates. I can't even edit the template I have access to. So by default, users are not given access to anything, you have to kind of implicitly tell them what they get access to and what to runoff. I also can't see anything outside of my team and my users in my organization. So I'm not going to go too much more into RBAC but it basically allows you to kind of assign and unassign what that particular user, team or organization has access to.

So I'll log back in as the admin user. And you can see how different that experience is. I get access to everything because I'm the admin. I can kind of lock this down by teams and groups. So I can actually see, let's see the network group we'll go in here. I might have set these up. Cisco was just filled by network and see that it is filter. It's not for a specific job. So these are accessed by network-admin. It should be the same password. So we will look at users, we'll say network-admin just as username. I think it's the same password, and you see he only has access to the network jobs. And if we look at the Inventories as the same inventory, but this could be locked down to only network nodes.

I didn't do that for this particular example because I'm just looking at job templates. But this is a way you can start sorting who has access to what gear when you're using the same Ansible Automation Platform cluster. Allows you to kind of break this into different groups and users and teams. Now the advantage of teams and organizations is I don't have to like deviate down by user, like user by user. So if I had 500 users, I wanted to assign to be able to run the job. I could just assign it to a team, import that team from LDAP and then assign it to the particular teams and Associate that job with it. So with that, let's move back into the slides and we will discuss workflows, which I think is one of the killer features of automation controller.