Share This:

Author’s Note: Most of the information listed in this blog is applicable to ITSM 7.5 and up, but screenshots and testing we’re conducted in an ARS/ITSM 8.1 environment. These postings are my own and do not necessarily represent BMC's position, strategies or opinion.


One important part of Asset Management is keeping tabs on the relationships between assets and the people they’re associated with. Simply noting that this person or this organization is associated with a particular asset is typically not enough information for asset managers to do their job. This relationship needs a description.

Out of the box, BMC Remedy Asset Management provides the following options to allow users to categorize their People-to-Asset relationships:

  • Approved by
  • Created by
  • Managed by
  • Owned by
  • Supported by
  • Used by

These relationships can be between an asset and a person, a support group, or an organization. What do these roles mean? Do they have special permissions or privileges? Where is this information stored if I need to create a report? How do I add a custom role? This blog hopes to answer these questions and more.


Defining your Relationships

All of these relationships come with predefined definitions per BMC documentation. Organizations implementing Asset Management may choose to define these relationships with more granularity per their own policies, procedures, and/or regulation.

  • Approved by – Individual/group who approved the CI, i.e. an individual approver on the purchase request
  • Created by – Individual/group who created the CI, i.e. “Receiving” or other group/individual responsible for processing CIs coming into the organization
  • Managed by – Individual/group who manages the CI, i.e. “Inventory Management” or other group/individual responsible for tracking the CI through its lifecycle
  • Owned by – Individual/group who owns the CI, i.e. the group/ individual who has fiscal ownership of the CI
  • Supported by – Individual/group who supports the CI, i.e. the group/individual that provides support and maintenance to the CI such as a help desk
  • Used by – Individual/group who uses the CI, i.e. the group/individual who has been assigned the CI for normal use

There may be groups that share multiple roles or you may not track all the roles in your organization. You may also choose to have a slightly different interpretation of the role definition than that described above.


Special Roles carry Special Privileges

When considering how to use relationship roles you must consider the special behaviors associated with some of these definitions:

  • The menu for the ‘CI+’ field on the Incident form will display a customer’s CIs if that customer or a People Organization (Company, Organization, or Department) they are associated with has a “Used by” relationship with that CI
  • The “Used by” relationship, when associated with a People record, creates a "Dependency" relationship in the CMDB
  • The “Used by” relationship, when associated with a People record, is used by the Software License Management engine when computing compliance for certain License Types
  • The “Created by,” “Managed by,” and “Supported by” relationship, when associated with a Support Group, allows members of that support group write privileges if the user has Asset User permissions (Asset Admin permissions supersede this and allow the user to modify all assets)

This information is summarized in the below matrix:



Select CI

in Incident?

CMDB Relationship




PeopleApproved byNoNoNo
PeopleCreated byNoNoNo
PeopleManaged byNoNoNo
PeopleOwned byNoNoNo
PeopleSupported byNoNoNo
PeopleUsed byYesYesNo
Support GroupApproved byNoNoNo
Support GroupCreated byNoNoYes
Support GroupManaged byNoNoYes
Support GroupOwned byNoNoNo
Support GroupSupported byNoNoYes
Support GroupUsed byNoNoNo
OrganizationApproved byNoNoNo
OrganizationCreated byNoNoNo
OrganizationManaged byNoNoNo
OrganizationOwned byNoNoNo
OrganizationSupported byNoNoNo
OrganizationUsed byYesNoNo


How do you add relationships manually?

To add relationships to a CI, you must have permissions to modify the CI. This means you will either have to have Asset Admin rights or you'll need Asset User permissions where the user is a member of a support group with a "Supported by" relationship of the CI. If you are operating in a multi-tenancy environment you will also need access to the company the CI belongs to or Unrestricted Access. See documentation for more details.


You can add these relationships manually or in bulk. You can add Individual relationships manually from both the user's People record (CTM:People) or from the CI record itself. If you are looking at the CI record, click on the "People" tab, click "Add," and proceed to choose the options relevant to the relationship you would like to create.


Add CI.png

If you are in the People record, you would click the "CIs" tab and click "Relate." To add Organization or Support Group relationships you must make the modification from the CI.



How do you add relationships in bulk?

If you have a large number of relationships to generate at one time, creating them manually can be very tedious. Fortunately, there is an option to load these relationships through the Data Management Tool (DMT). There are many steps to loading, validating, and promoting data through the DMT , which I will not cover here. However, there is some great information at our documentation site.


When using the DMT to load People Relationships, you will want to use the "AST_LoadAssetPeople" tab in the "Transactional_Asset" spreadsheet.



Where is the relationship information stored?

All People-CI relationship data is stored in AST:AssetPeople, which is installed with the installation of Asset Management. This includes Support Group and People Organization relationships. This form stores all the information regarding the relationship but does not have a lot of data regarding the CI or the related person/group.

AST:AssetJoinASTPeople and AST:AssetPeople_AssetBase are out of the box joins between AST:AssetPeople and AST:BaseElement. This join form could be used for reporting if more information regarding the CI is necessary. You can also develop your own custom joins based on your individual reporting requirements.


Not enough options? Add!

The six roles above encompass many responsibilities in an asset’s lifecycle. But what if your organization has a requirement to track a different type of relationship? Here are the steps below to accomplishing just that:

  1. Using your browser or client, navigate to the "SYS:Association Types" form and create one record for  your new Relationship Type and create an additional record for whatever you enter as the "Opposite Relationship Type." Note the Relationship Type and Selection Code entered as you will be using these later when modifying menu choices  AssociationTypes.png
  2. Navigate to the "SYS:Association Type Assoc" form and create one record for the new Relationship Type. Select "AST:Configuration Item (CI)" for the 'Related On Form Name' field and "People" for the 'Request Type' field. You would repeat this step for People Organization and Support Group, changing the Request Type value respectively.    AssociationTypeAssoc.png
  3. In Developer Studio, add the Relationship Type as a menu choice to the fields and forms below. Use the Selection Code you designated in step 1 as the choice's ID:
    1. Form: ”AST:dlgSelectASTUserOwner”, Field: “Association Type01”
    2. Form: "AST:CI Associations",  Field: ”Association Type01”
    3. Form:"AST:AssetPeople", Field: ”PersonRole”
  4. Verify that the 'Role' field on "AST:AssetPeople_AssetBase" and ‘People Type’ field in AST:AssetJoinASTPeople have the updated values as selections in the 'Association Type01' field. If you are making changes using Overlays you will need to overlay this form, its views, and the 'Role' field.
  5. Test! Before implementing this change in production please test this in a development.


This information can also be found in our knowledge base (KA401006).


Please keep in mind that this is considered a customization and will be supported as such per BMC's Customization Policy. Customizations should be used in the rarest circumstances where thorough analysis has concluded that the existing functionality out of the box does not support important business processes and must be extended.


Wrapping it up

Capturing people relationships can be a daunting task if you do not have strong internal policies and procedures in place that capture this information and keep it up to date. Despite the hard work that goes into this, the information captured here is important. It not only tells you the “who” associated with your assets but also helps calculate Software License information and also supports Incident Management processes. I would encourage you to consider implementing this functionality if you have not done so already. If you have, I would encourage you to share your experiences in the comments below. Thanks for reading and have a great August!!