Access roles – Granular part of access group.
Let me bring the authorization model again.
- Amazon organization opt for a single application for 2 different divisions – Sales & Service.
- They have individual manager for the two divisions and group of users(call center agents) work for their respective division.
We have different functionalities out there.
1. Users can create cases respective to their divisions.
Sales can create only sales case. Service can create only service case.
2. Managers can create any case irrespective of their divisions.
Managers can create both sales as well as service cases.
3. Both don’t have the administrator role.
We have different group of people as Amazon administrators.
Now let’s come to our Pega.
Step 1: From the above requirement, you can see three different group of peoples – Sales, Service, Admin.
Create 3 Access groups.
Now group is ready. “What is the next step?” – Yes, roles.
Step 2: Every group will contain certain roles right.
Take any political party 😀 , you may faint if you check the hierarchical roles. Huh, Leave it.
Here, Sales/Service access group have a manager role and a user role. So, what you do?
Create 2 Access roles for sales & service. (For time being don’t care admin group).
Now roles are ready.
Access role to Objects (ARO)
Objects – Here refer to any concrete class instances.
You can explain the ARO functionality from its name.
Providing access to access roles for particular instances. We can provide access to user access role for sales cases.
Access role – Sales : User
Object name – Sales case
I don’t want to make this a very big post :). The other two topics, ‘Access Deny & Privilege‘ (http://myknowpega.com/2017/05/19/access-deny-privilege/) will handled in different post.
What is an Access role?
- It defines a role in an organization and provides the capabilities for that role.
- Providing capabilities mean, you can provide or restrict access to certain class instances.
What is an Access role to Object?
- It is the capabilities people can take on any instances.
- They can either create, update or delete any class instances. We can restrict these in ARO rule form.
How do we configure an access role & ARO?
- When you create a new application – Default access groups and roles are created automatically.
Preview the records.
2. Manual creation
- Access role is part of Security category.
Step 1: Create a new Access role.
Note: Please have this naming convention “Application name:Role name”
I created for SalesManager.
Step 2: You will get a blank rule form. Save it first.
Step 3: Fill out the single main tab – Role
a) Clone from – Yes you are gonna do cloning 🙂 – Means you can clone a copy from any existing access roles.
Check on the drop down.
It lists all the existing access roles available.
- Remember Fkart:Manager, User, Admin are created at the time of application creation.
Let’s check the FKart:Manager role before cloning.
Please note there are many access class when you scroll till the end.
You may get a question. “What do they really mean?“
Access class are nothing but Access role to Object 🙂
We know Access role can contain many AROs.
If you need to create a new role for manager access group, then try cloning the existing manager access role and override it.
- So we will clone Fkart:Managers to Fkart:SalesManagers.
After selecting a clone access role, click on the clone button to complete it.
You will see all the AROs in new Access role.
You can verify the ARO on @baseclass gets cloned from FKart:Managers access role.
b) Access class grid
It list all the access role to objects (ARO) applicable to the Access role.
You can scroll down to the end and use + icon to create a new ARO for this role.
Initially, just give the class name alone. I gave my Sales case class Name.
FKT-FKart-Work-Sales. Click save.
You can see the ARO added at the end in Access role rule form.
So what you achieved is, you have successfully added the ARO to the new class.
Now, you can go to records and check out the ARO & open the rule.
How to configure Access role to Object (ARO) form?
You can create ARO in many ways:
- Manually, by creating a new ARO. (Normal rule creation)
- Using Access role grid. ( What we saw above)
- Access Manager – We will see at the end.
Now let us check our access role.
You have 3 main tabs:
Privileges & Settings will be discussed in their respective topics.
Access controls – You specify the access control for various options.
In the fields you can provide, either level values (see at the right) or access when rule (Replica of when rule).
Say you provided Level value 5 – Then it will be application till production environment.
- Open Instances – Controls whether you can Open FKT-Fkart-Work-Sales cases
- Modify instances – Controls whether you can Save FKT-Fkart-Work-Sales cases
- Delete instances – Controls whether you can delete FKT-Fkart-Work-Sales cases
- Run reports – Controls whether you can run reports of applies to class FKT-Fkart-Work-Sales
- Execute activities – Controls whether you can run reports of applies to class FKT-Fkart-Work-Sales
- Open rules – Controls whether you can open rules of applies to class FKT-Fkart-Work-Sales
- Modify rules – Controls whether you can modify rules of applies to class FKT-Fkart-Work-Sales
- Delete rules – Controls whether you can delete rules of applies to class FKT-Fkart-Work-Sales.
It’s time to test 🙂
Step 1: Follow all the steps above.
New access group -> New Access role -> New ARO for your work class (case class)
Step 2: Make open modify, delete instances to 0 or null. (both restricts authorization)
Step 3: Verify that the access role is added to your access group.
Step 4: Verify that the Operator ID is tagged to that Access group.
Step 5: Login the Operator ID and create/Update a case.
You can change the Access level for different controls like run reports in ARO and verify various functionalities.
Now let’s come to the most important topic.
This is the recommended approach by Pega for creating AROs.
Since this is vast, I am going to tell you how you can control AROs alone.
I will explain ‘Access Manager‘ in separate post.
Designer studio -> Org & Security -> Access Manager -> Work & process
Opens up a landing page.
Now, open our access group FKart:SalesManager
You can see the legends for Full access, No access and Conditional access.
Full Access – Updated the respective ARO – 5
No access – Updates the respective ARO -0
Conditional – We can specify Access ‘when’ rule
After submitting, you can verify the ARO rule form for sales class.
It will get updated automatically. See how Pega reduces the developer workload 🙂
Cool right?! Pega makes it everything as a simple configuration 🙂
Finally we will test something different
Step 1: Delete the ARO, we created 😦
Step 2: Go to Access manager and refresh.
“Are you wondering, how this is populated? We deleted it, right?“ Here, it follows the inheritance path and gets the ARO specified.
Hope you can correlate now. Yes, it is inherited from Work-class.
Let us update the ARO from access manager
Update for sales case – Open as restricted – Guess what happens?
Yes, Pega creates a new ARO, if not available. If it is already available, then it updates.
How do you debug the access roles?
- You can check out the clipboard.
System pages -> Access group -> pyUserRoles
Hope you are clear now with the Access group basics.
Wait for my next post on ‘Access Deny, Access When & Privileges‘ (http://myknowpega.com/2017/05/19/access-deny-privilege/)🙂