CMS Idea Exchange

We need to detect the Last Discovered Time of a CI

Please provide a Last Accessed By attribute (and associated functionality to populate/update the attribute). This would be associated with the Last Access Time, similar to how to Create Time and Last Modified Time are associated to the Created By and Updated By fields (respectively).

Today we only have the Last Access Time to work with but don't know what process keeps touching the CI (for example, a CI is never a candidate for deletion because some process keeps it active by "touching" it).

Super Contributor..

Exactely. But even more we need dedicated attributes called for instance LastDisoveredTime and LastDisoveredBy and LastDiscoveredFromProbe that would be filled and changed only by Universal Discovery (in contrast to Last Access Time). So for every CI it would be easy to answer the key questions like :

  • Was this CI discovered ?
  • When it was discovered last time (i.e. discovery detected it as "live or active" last) ?
  • What discovered it last time ?
  • Wchich probe did the last discovery?

So essential info required by IT audit, compliance processes etc.

Best regards



Honored Contributor.

Great feedback from Ivan there.

Acclaimed Contributor.
Micro Focus Expert
Status changed to: Waiting for Votes

The idea has received an initial review to ensure adherence to our idea submission and community guidelines. We ask the community to help prioritize the idea with comments and community support (votes/kudos).

Super Contributor..

Hello Johnc3,

thank you for the link. Indeed. But we need even more complex and professional solution. The solution for auditing, compliancy and IT management. Simply answering the essential question whether was a CI discovered, and if when, by what and from where.  Only 3 simple new attributes dedicated to UD would be enough :




I am shocked that in 2018 UCMDB/UD misses this essential metadata... 

Have a nice day


Super Contributor.

Assuming that "LastDisoveredBy" is the job, knowing the trigger CI would be important too.

Honored Contributor.

Another thought on this.... while having last accessed/discovered/time etc is important, should that data not be available in a historical manner? Meaning I think we need to see the last 5 or 10 iterations of last accessed/discovered/time in order to effectively troubleshoot.  Perhaps the "last accessed" attribute should be displayed but each iteration should be logged and available for reference. 

Super Contributor.
Super Contributor..

Hello Doron & Dimitry,

the story is about something else. ThisER "Add atrribute to show which activity/event updates Last Access Time attribute - Document ID : QCCR1H112054" doesnt solve the key weaknesses of UD/UCMDB - it doesnt provide sufficeint information for IT audits, compliancy checks, IT governance  and service provider use. Please relizae that Last Access Time attribute is intended for Aging mechanism (and works fine for this purpose). We need to add new attributes dedicated for Universal Discovery (that would be filled/updated only by UD - and not by user interactions nor integrations etc.). These attributes would say clearly this :

LastDisoveredTime - when was the CI discovered, If null then never otherwise the last time when the discovery detected ti in the IT environment. 
LastDisoveredBy - the job wchich discovered the CI last
LastDiscoveredFromProbe - the DFP that discovered the CI last 

So there attributes would have nothing to do with Last Access Time!   But of course adding Dimitry's attribute "Last Access Time Updated By" would be welcomed too :)))



Micro Focus Frequent Contributor

Hi Ivan,

but would the combination Last Accessed By together with the Lasst Accessed Time Attribute and its related history not also cover your demand?
I mean Last Accessed By would of course cover more infromation - not only UD - but I guess data accessed by integrations or enrichments is as important for autis and so on as from UD. And regards user interaction: Whenever a user does something to a CI it is not only an accessed by but also an updated by or do I forget something here?

If we only cover UD data then we can still come to a point where we don'T know exactly why a CI stays alive and doesn't get a CfD. 
This would mean if we have MORE than what you ask for, you can still filter for only the information you need.
So from my opinion the only addition to the orginal request (which is a wish also from me for quite some time especially for the "not getting CfD" topic) for your use case would be the probe information.