3 of 3 people found this helpful
Before you go this path, I would suggest if you can share more detail about your use-case.
Permission for updating and maintaining CI can go from CI i.e. whole CI with all the attributes to individual attribute level permission. This can become even complex depending how each CI owner plays a role in the IT and what attributes are accessibleto them.
Majoirty of CMDB CIs are discovered by the discovery tool, but it has been supplimented with ITSM attributes (e.g. Life Cycle information, cost related attributes etc.) by Asset management users (typically admins) Here, their role will differ the CI permission too.
The answer is - It depends on your use-case and what do want to achieve and a business need.
1 of 1 people found this helpful
Thanks for responding. I will try to set the scene for you and provide some background and details on the topic.
We are new adopters of the Remedy toolset and indeed new to the concept of fully fledged CMDB functionality. Up until now our focus has been on the capturing of data and the population of the CMDB. I have a small team of analysts and through our experience of the CMDB so far we have identified a need to build up a community of CI owners to maintain the accuracy of the data across the estate of CIs given its volume.
We see 2 strands to this:
1. CI owners updating the attributes of CIs where they have a 'Supported By' relationship. The attributes I would anticipate them needing to update would primarily be the life cycle attributes and things like the description and environment fields. There would be 2 flavours of CI owner. The first being application/system support teams who would be updating application CIs but perhaps not components such as servers (with exceptions to this rule). The second being our infrastructure teams owning the more granular components underneath the application CIs.
2. CI owners being able to create impact and dependency relationships between CIs where they have the ‘Supported By’ relationship in common across the CIs. At the moment my understanding is that this is only possible with Admin rights or a customisation of permissions.
We are not proposing that CI owners make changes to discovered elements of CIs. But we do however have a number of CIs in non-discoverable zones and would have a need, in those examples, for the attributes to be completed manually where possible.
I hope that has made things a little clearer. I appreciate you taking the time to advise on this and happy to clarify any further points.
I had a discussion with my colleague from ITSM and this requires bit more time and effort to provide more detail.
Can you please create a support ticket and ask to contact me on this front.
Hi Manish - Thanks for your responses on this matter. I am happy to continue to have a technical conversation on the art of the possible with in the toolset and am speaking to Sam regarding the support ticket.
To the wider community - I would be very interested to hear from anyone who has implemented the concept of CI owners updating their owned assets and the approach taken when identifying the attributes and permissions granted to make it a success.
2 of 2 people found this helpful
I had an internal discussion other folks and here is some theoretical approach.
You can achieve CI Owner concept similar to CMDB Write Security which allows CI access to the user/group as part of CMDBWriteSecurity attribute belongs to BMC_BaseElement class. The difference in your case that the permission will be limited to certain attributes of CMDB class.
1. Create CIOwnerSecurity Group Similar to "CMDB Write Security". i.e. Group Category will be "Dynamic" and Group Type = "Change"
2. Add new attribute in BMC_BaseElement class e.g. named OwnerSecurity (make sure to provide the same field id as the group id belongs to "CIOwnerSecurity" group created in #1)
Note - This field will be used to keep a list of users (i.e. login-id which will have CIOwner permission to modify certain attributes).
Dynamic groups are similar to the Assignee Group (field ID 112), except that they are defined by the developer and include field and group IDs in the range of 60000 to 60999. For example, when you create a group with group ID 60000, its user list includes the individual user name or the members of any group or role that appears in field ID 60000." - doc reference.
3. Add CIOwnerSecurity Group to the required attributes e.g. description, environment with change permission rights. On CMDB side, you can achieve this using CMDB Class Manager.
4. BMC_BaseElement has an attribute called "Owner Name". This attribute can be utilized to populate an owner/ or list of owners which is human readable names. Now, There a piece of custom workflows required to populate OwnerSecurity attribute with login-id based on the list of owners present in "Owner Name".
Disclaimer - The whole approach seems very logical, but I haven't tested by myself. I rushed to respond you since it's been long time on this thread.
Thank you very much for taking the time to look at this. Our preferred approach is to take OOTB functionaloty as far as is possible and adopt a process solution. But this is certainly worth bearing in mind and it is good to know that a technology is option is potenitally available.
I have not tackled this one but have had the same requirement in multiple organizations I have worked for. I contend this is not a corner use case and may be more common than BMC realizes. I understand the line between CMDB and AM but it nearly impossible to explain to users. Understanding these are two different disciplines on paper, I think this line in the sand between CMDB and AM should be, if not removed, made invisible because it causes roadblocks for many organizations that do not see value in (or cannot afford the staffing) to treat these as two different disciplines.