SMA Idea Exchange
cancel

Allow more data to be accessible between different entity types

Hello,

There has been an increasing amount of pressure from Customers to include extra information in their reports and in their views. For example, in order for a user to show the Organizational Unit of the Assignee in a view, there is only one option:    

  • bring the extra information in a new field, by running a custom rule during the lifecycle of a record in order to fill information in the field. This approach is only possible for only two fields per entity type (max custom searchable fields with filter functionality=2)


Ideally, we should not have duplicate data without reason: the data is in SMAX and we need a way to access it using multiple ways. Unfortunately, ENTITY_LINK fields do not allow this functionality right now. We can, for example, use something like "assignee.DistinguishedName", but not "assignee.OrganizationalGroup", because DistinguishedName is "SMALL_TEXT" type field and OrganizationalGroup is "ENTITY_LINK"

Either increasing the amount of custom searchable fileds or allowing data to be fetched from ENTITY_LINK fields will improve the functionality of many heavy users who need some simple additional data in their everyday use of SMAX, without resorting to 3rd party tools.

For anyone who has used HPSM in the past, I am referring to a jscall(context.GetValue, , , ,) equivalent :-)

Thank you,

Ioannis

2 Comments
Micro Focus Expert
Status changed to: Waiting for Votes

Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team

Note - while technically the # of votes would normally warrant a review from the products team, we're leaving in this status as at least 10 of the votes are from the same company. Once there is more traction from the community, it will be reviewed. 

Super Contributor.

Hello again,

It is very important to keep the Customers' involvement in the product as high as possible. We don't want to encourage them to use a third-party program to access SMAX data that is already present in the system. Something simple like filtering a Request Report by the Organizational Group of the Assignee should be supported. Besides, we are not talking about complex table joins. Letting loose some of the constrains that SMAX imposes will add value to the product.

Thank you,

Ioannis