How To Assemble Flexible Business Roles

Assembling business roles is not a simple task. There are many things to be considered in business roles design.

What is the purpose of the business role?

Why we should use it instead of assigning direct privileges in all the systems?

Well the answer is pretty obvious here. The business role gives us opportunity to manage any set of direct assigned privileges regardless of the system, like single object. Handling single role is more easier, than handling hundreds of privileges in different systems.

Ok, but then someone may say, "Yes but we are loosing flexibility this way?"

And, yes, he might be right, but only if we didn't built our business roles in a proper manner.

Ok, but how we can keep a small number of roles and still achieve a flexibility?

Well this is the question I'll try to answer with this blog.

There are basically to ways to have small numbers of business roles and still keep them flexible enough.

Using business role inheritance

This method is suitable for companies where the persons may be separated in several areas with several subareas where the subareas inherit all access rights of all parent areas. For an example see the following picture.

As we can see each position inherits access rights form the lower one. In this case we can assemble following business roles.

This way the MANAGER BUSINESS ROLE inherits all assigned privileges from STAFF BUSINESS ROLE and BOSS BUSINESS ROLE inherits all privileges from MANAGER BUSINESS ROLE and STAFF BUSINESS ROLE.

As a result we may now assign only one business role per position.

This way is much easier than assigning for a BOSS position 3 separate business roles, if inheritance were omitted and it is definitely easier than assigning all 7 privileges directly, if business roles were omitted.

Of course this is very simple scenario and in real life scenarios you will have more than one basic business roles and each business role might inherit more than one of its kind, but I'll stay with simple scenarios in sake of easy understanding.

Using contexts

This method is suitable for companies that does not comply with previous method of inheritance, but the access rights might be separated in groups based on some keys (i.e. position, country, location, etc.)

As you can see here we have completely different situation. There is no inheritance of privileges between positions, so the question is:

How much business roles we will have in this case?

Well the answer is 3 business roles and this is not a typo. Let's see how this might be accomplished.

As you can see the business roles are 3 and they contain all the privileges that one person on STAFF position might have for example.

But the question here is:

How we will assign exactly and only these privileges the person on STAFF position in US PLANT needs?

Well the position (STAFF), country (US) and location (PLANT) are actually attributes of MX_PERSON, so we have these information for all persons that we should provide access rights for. After we have that information the assignment is easy.

According to person's attribute (position) the business role is selected and attached to the person with contexts defined from person's attributes (country and location). As a result only privileges that are matching all these conditions will be attached to the person.

As a conclusion it is also possible to use mixture of both methods if you have a complicated case that fits, but basically these are most common scenarios for building small in numbers and flexible business roles.

Hope I've been helpful, but if you have any other suggestions or questions, please feel free to post them here.

Best regards,

Ivan