Share This:

In this post, I will describe the concepts and importance of “Share Services” feature in BMC Cloud Lifecycle Management. By taking a closer look at how this functionality works, we can understand the behavior observed in the application at a deeper level, which will help you troubleshoot any issue observed during implementation.

Until BMC Cloud Lifecycle Management 4.0, End users are not permitted to perform control or management operations on SOIs they do not own, and the system does not support granting an end-user such permissions.

From BMC CLM 4.x onwards, Cloud user (TA/CA/end user) can share a SOI with other CLM users and groups of his/her organization using any of the following:

Using operator action “Share SOI” for the existing SOI – Same action can be used to edit/remove the list of shared users/groups.


Once the SOI is shared, only Cloud Admin/Tenant Admin/SOI owner can revoke/edit the list of shared users/groups.

The end users with whom SOI is shared have full access similar to the SOI owner. The only thing shared end users are not being able to do is extend sharing to other users.

Following table illustrates the changes performed on Configuration Item (CI) when we share the Service Offering Instance:


RoleExisting OwnerData in CMDBRowLevelSecurityOwner Name Field
Share ServiceCA/TA/EUTenant Admin or End UserWe retain existing permission + 'new user id'No Changes


Following example will help you understand the changes in "CMDBRowLevelSecurity" field:

Before Sharing SOI:


After Sharing SOI with user 'arp_eu1':


Sharing Services creates a Relation between Service Offering Instance and BMC_Person only for the shared users.


Shared example can help you to troubleshoot the issue if an user, to whom you have shared the services, do not see the services to manage.

Following are the logic/validations while sharing the services (SOI):

1: Only Cloud Admin/Tenant Admin/SOI owner can share/revoke/edit the list of shared users.

2: The users with whom SOI is to be shared exists in DB and are all Cloud users (Cloud Admin/Cloud Org

Admin/Cloud End User). This user list can be empty. This will remove the sharing the SOI with all existing shared users.

Here is how we fetch the privileges and other information of an user with whom you share the SOI.

Snippet from CSM.log:

24 Feb 2015 12:11:15,962 [DEBUG] WLM - [Thread=80d935ba-0723-42a3-a332-efba5846217d::614b4467-f3cc-4bae-bba5-61b6b9612ef3::60037226-5b4a-421c-a2a7-2656036cc1bc(169)] [Class=ServiceOfferingInstanceShare:getUserFromDB] - t1cloudenduser2 User object from DB for -{

  "cloudClass" : "",

  "firstName" : "Cloud",


  "lastName" : "EndUser2-T1",

  "name" : "t1cloudenduser2",

  "organization" : [ "/organization/AGHAA5V0H4FYPANEANY5YTGVSWZGMP" ],

  "userName" : "t1cloudenduser2",

  "userPrivileges" : [ "/privilege/1500000001", "/privilege/20601", "/privilege/1000000009", "/privilege/20600", "/privilege/20000" ]



In above example, privileges are the "Group IDs" in Group form.


3: The user's organization is same as SOI's organization.


4: Filtering of all admins(CA/TA) from the user list. Since the SOI is already accessible for admins,

these will be excluded from the user list if any exists.

For example: Here is the error you receive when you share SOI with Cloud Org Admin:

24 Feb 2015 12:11:15,963 [ERROR] WLM - [Thread=80d935ba-0723-42a3-a332-efba5846217d::614b4467-f3cc-4bae-bba5-61b6b9612ef3::60037226-5b4a-421c-a2a7-2656036cc1bc(169)] [Class=ServiceOfferingInstanceShare:validateUser] - The users [[t1cloudenduser2]] already has access to Service Offering instance AR-RHEL-x86_64-ROD-version1-27


5: Update sharing of SOI and related CIs. This will append the user list to the existing CMDBRowlevelSecurity and will add the relation of SOI and BMC_Persons for the list of users with whom the SOI is shared.


Sharing can be done for all SOI states except Decommissioning, starting, stopping etc. It's only allow if the states are Running, Stopped & Installed.

CMDBRowlevelSecurity and BMC_Person Relationshsip with SOI will be updated for most of the following cloud classes at different layers:

Cloud Class




















Other References:


A new form "CMF:SYS-Access Permission Grps" has been introduced to support "Share Service" feature and has following descriptions:



1: This is an intermediate form introduce to generate the Group ID dynamically.


2: The group id range generated by this form for ‘Tenant Admin Group’ would be between 1500000000 to 1599999999


3: This form is used by ‘Migration Script’ and ‘Tenant Management’ UI to generate the ‘Tenant Admin’ group for on-boarded Tenants.


This group would then be used for assignment of the users created with ‘Cloud Organization Admin’ permission.


4: The Group Name and Group ID are auto generate by this form.


Following two filter are modified on the “BMC.CORE:BMC_BaseElement” form.






Above filters fetch the ‘Tenant Admin’ group from the “CMF:SYS-Access Permission Grps” form and update the CMDB Row level security field with the ‘Tenant Group ID’ for the respective ‘Tenant’ the CI’s belong to.

Refer Sharing services with other users

I hope this information is useful to understand this feature and troubleshoot any issues, if observe, on your own.

You can also join the Customer Support Community to learn about and provide feedback on ways Customer Support can enable your success.

Visit CLM Blogs. You can share the links with others if you find these useful.


Please rate this blog, regarding the usefulness of the shared information, by clicking below option.