This article by Rachel Orti and Melanie Shilpa Rao is for Operational Decision Manager (ODM) users who want to manage the access and permissions when authoring decision services with ODM on Cloud.

Introduction

When implementing decisions with ODM on Cloud, decision services are stored and accessed in Decision Center, which is the shared platform used to author and administer decision services. Because decisions often contain strategic data, you may want to restrict the access to decision services in Decision Center.
The following use cases are considered:

• Basic: You have several decision services in Decision Center and you would like to give different access rights to these decision services.
• Advanced: Among your decision services, you have a decision service made up of different rule projects and you would like to define fine-grained access and permissions for each individual rule project within the decision service.

This article explains how you can use the new permission management capability in ODM on Cloud to implement these use cases.

Scenario

A car rental company has two departments: one for short-term rentals and one for leasing. Both departments want to use ODM on Cloud to implement their pricing policies. This is done by implementing two different decision services: one for the short-term rental department and one for the leasing department.
The following diagram illustrates the hierarchical structure of the company.

All the people in the marketing, legal and IT teams will be involved in the decision service authoring in the company.

Inviting users and setting up the user roles

When a company requests an ODM on Cloud instance from IBM, they have to provide the name of someone who will be Cloud Administrator for their instance. The role of the Cloud Administrator is to manage user accounts for the company.
John has been assigned this role for the Car Rental company. To give access to the ODM on Cloud instance to his colleagues, John uses the Admin tab of the ODM on Cloud portal to invite them to the instance and to assign them an ODM role.

The ODM role of each person is chosen depending on his or her role in the decision service authoring:

• Release Manager for people managing the development process of decision services: Frank from the IT team
• Rule Developer for people modeling and publishing decision services from Rule Designer: Kim from the IT team
• Integrator for people integrating and validating decision services: Arjun from the IT team
• Business User for people authoring decision artifacts in Decision Center: people from the marketing and legal teams
• Permission Manager for people managing access and permissions on all decision services: John himself

Note: The Permission Manager can be someone other than the Cloud Administrator.
All the invited users receive an email allowing them to activate their access to the ODM on Cloud instance.

Enforcing security when publishing the decision service

Frank, the Release Manager, contacts Kim as Rule Developer to discuss the decision services that need to be created. He tells her that the access to these decision services should be restricted to the people who are working on them.
Once Kim has activated her ODM on Cloud access, she downloads Rule Designer from the portal. Then she starts modeling the “Car Rental Service” and “Car Leasing Service” decision services locally.
When these decision services are ready to be shared in Decision Center, she publishes them from Rule Designer, selecting the governance mode and the enforced security, to prevent anyone other than John and herself to access the decision services. John can later configure the access in the Decision Center Business Console, at the decision service or dependent rule project level.

Note: Enforcing security on decision services restricts the access regardless of the way used to access them, whether it is done by logging on to the Business Console or by synchronizing them between Rule Designer and Decision Center.
Now that Kim has finished publishing, she tells Frank that the decision services are available in Decision Center. If she logs on to the Business Console, she can see both of the decision services in the “Library” tab.

If anyone else other than Kim and John logs on, they will not see any decision services as shown below.

Setting up the access for the decision service

Frank as Release Manager contacts John, the Permission Manager, and asks him to set the access on the decision services. He tells him who should have access to the decision services.
Going to the “Administration” tab of the Business Console and then to the “Project Security” tab, John can see the decision services published by Kim. The groups “Car Rental Service” and “Car Leasing Service”, which were created automatically during the publishing, have access to their namesake decision services.

Basic Use Case: Setting up the access for a whole decision service

For “Car Rental Service”, Frank has told John that he himself needs access, along with Kim and Arjun, as well as Claude and Li from the Short Term Rental Marketing team.
Going to the “Groups” tab of the “Administration” tab and editing the existing “Car Rental Service” group, John can see that Kim already belongs to it, because she published the decision service. John adds Frank, Arjun, Claude and Li to this group.

As members of the “Car Rental Service” group, Frank, Kim, Arjun, and Claude and Li are now able to access this decision service in the Business Console.

Advanced Use Case: Setting up fine-grained access for the rule projects of a decision service

For “Car Leasing Service”, Frank has told John that he needs more fine-grained access. Indeed, this decision service has several dependent rule projects, and people working on this decision service must only have access to the rule projects required for their work.
The following diagram illustrates the structure of the “Car Leasing Service” decision service.

The “Car Leasing Service” main rule project contains the main ruleflow. The “Car Leasing Base” rule project contains the Business Object Model (BOM) and the vocabulary. The “Car Leasing Eligibility” and the “Car Leasing Pricing” rule projects contain the decision artifacts that determine the eligibility and the pricing, respectively.
The following people are going to work on the “Car Leasing Service” decision service:

• Release Manager: Frank
• Rule Developer: Kim
• Integrator: Arjun
• Business Users: Paul from the Legal team, and Gary and Carmen from the Leasing Marketing team

All these people need to have access to the decision service. However, Frank wants fine-grained access, so instead of adding all these people to the “Car Leasing Service” group created by default, John must create several groups to restrict the access to some rule projects.

Creating groups to implement fine-grained access

To know how many groups John must create to implement the fine-grained access, he must first know in detail who should have access to which rule project in the decision service. Frank tells John that:

• Frank as Release Manager should have access to every rule project.
• Kim, being the only Rule Developer, should also have access to every rule project in case she has to update the BOM and the vocabulary and has to help Business Users to implement complex policies.
• Arjun as the Integrator does not need to see the policies so he should only have access to the main rule project.
• Paul from the Legal team is going to author eligibility policies so he should only have access to the “Car Leasing Eligibility” rule project.
• Gary and Carmen from the Leasing Marketing team are going to author pricing policies so they should only have access to the “Car Leasing Pricing” rule project.

Now that John knows who should have access to which rule project, he can determine the groups required to implement the access policy requested by Frank:

• “Car Leasing Service” group (already created by default): for people having access to all the rule projects of the “Car Leasing Service” decision service; should contain Frank and Kim
• “Leasing Eligibility Authors” group: for people dedicated to the authoring of decision artifacts in the “Car Leasing Eligibility” rule project; should contain Paul
• “Leasing Pricing Authors” group: for people dedicated to the authoring of decision artifacts in the “Car Leasing Pricing” rule project; should contain Gary and Carmen
• “Leasing Validators” group: for people who should have only access to the “Car Leasing Service” main rule project; should contain Arjun

Kim was already added to the “Car Leasing Service” group when she published the decision service, so John only adds Frank to this group.
For people dedicated to the authoring of decision artifacts in the “Car Leasing Eligibility” rule project, John creates the “Leasing Eligibility Authors” group by clicking the “+” button in the “Groups” tab of the Administration tab in the Business Console. In the dialog, he sets the Permissions to “Full Authoring” and adds Paul to the group before completing the creation of the group.

For people dedicated to the authoring of decision artifacts in the “Car Leasing Pricing” rule project, John creates the “Leasing Pricing Authors” group with the Full Authoring permission and adds Gary and Carmen to this group.
John creates a last group “Leasing Validators” with the Full Authoring permission for people who should have only access to the “Car Leasing Service” main rule project and adds Arjun to it.
After he is done, John can see all the existing groups in the “Groups” tab.

Restricting the access on the decision service’s dependent rule projects

Once all the groups who should have access to the decision service are created, John has to set them on the decision service before restricting the visibility at the dependent rule project level.
To set groups on the “Car Leasing Service” decision service, John goes to the “Project Security” tab and clicks on the “Edit” icon, which appears when he hovers on the name of the decision service. This opens a dialog where he can add all of the groups that need access. The “Car Leasing Service” group is already selected by default. John also selects the “Leasing Eligibility Authors”, “Leasing Pricing Authors” and “Leasing Validators” groups.

These groups are added for all the rule projects and all the branches of the decision service, as can be seen in the “Project Security” tab.

Then John restricts the access to the dependent rule projects from the main branch. Restricting the access at the main branch level also restricts the access to all the branches and releases because security settings are inherited from the main branch by default.
Expanding the decision service and the top level “main” branch, John clicks on the “Edit” icon of a particular dependent rule project to restrict which groups have access to it. For the “Car Leasing Eligibility” rule project, he keeps the “Car Leasing Service” group who should have access to all the rule projects and the “Leasing Eligibility Authors” group who should have access to this particular rule project, and he deselects the other groups. Only the people from the “Car Leasing Service” and “Leasing Eligibility Authors” groups now have access to the “Car Leasing Eligibility” rule project.

Once he has finished editing the security for all the rule projects, he can see which groups have access to which parts of “Car Leasing Service”. Any releases that depend on the “main” branch inherit the same access settings by default.

John lets Frank know that the fine-grained access is set up. Frank and his team can now start working on “Car Leasing Service”. Indeed, if Frank logs on to the Business Console, he can see the Car Leasing Service decision service in his “Library” tab, and in the “Decision Artifacts” view, he can see all of the dependent rule projects.

Paul, on the other hand, can only see the main rule project and the “Car Leasing Eligibility” rule project as expected.

Conclusion

In this article we introduced the new permission management capability in ODM on Cloud. We provided some examples of how this feature can be used to restrict user access both at the decision service level and at the dependent rule project level, focusing on Full Authoring permissions. Permission management can be used in more ways, for example with Read Only permissions to give viewing access only, or by overriding access at the release or activity levels.
For more information about ODM on Cloud, visit the ODM on Cloud Knowledge Center.