Force APM Business Capability hierarchy ID

[Jim Federline]

I am planning a migration of our company's existing business capability map into APM. I've run into a snag - we already have assigned hierarchy ID's. But ServiceNow attempts to manage these itself. I need to replicate the hierarchy by ID - I cannot accept "whatever ServiceNow generates".

In playing around with things here, I've think I've found a way that I can "stack the deck" with the exact hierarchy ID's that I want. It is be better for an organization with their own existing capability map, which is likely indexed with hierarchy ID's already, to defeat the auto-numbering in ServiceNow somehow. It would be best if ServiceNow APM allowed this explicitly.

Here's what I did; I'm looking to find out if this is acceptable:

1. For non-leaf nodes, I used the "Order" field. This worked good for the root nodes. However, it does not work for the leaf nodes below it - it is seemingly ignored. If this had worked, I would not have had to do #2, next...
2. For leaf nodes, after I input them, I was left with hierarchy ID's that did not match our internally published capability map. One cannot modify Capability ID in a Business Capability form UI. But, you can in a list view. You have to be careful not to create duplicates at any stage, or it doesn't work. But if you are careful, the ID's seem to stick through subsequent executions of the "Update Capability Level and HierarchyID" UI Action.

CORRECTION added as an "edit" to this post:  I was mistaken. #2 does not make it stick in some cases, which I cannot pin down. 

I dislike that I need to do this. I would like the "Update Capability Level and HierarchyID" UI Action to, say, honor the "Order" within a level under a parent.

Thoughts? Does anyone else have an enterprise that has already indexed a capability map?

[PRAJ NAIR]

We have the exact same problem. My understanding is that this may get better with the NY release. 

If you've had any success with this let me know. Would love to learn how your team addressed this. 

Thanks, 

[yogesh41]

Similar feedback has already been considered, the product team is planning to make hierarchy id configurable or have own custom hierarchy id. It should be available soon. Thank for valuable feedback. 

- Yogesh 

[johnflannagan-y]

I am having this issue as well.  And even on the most current New York release can not seem to get the system assigned hierachy id to align with the what is needed.  For some reason, the system seems to pick an order ahead of what is being loaded.  While close, is causing issues and confusion.

Did anyone ever come up with a solution to this?

[Jim Federline]

Hi John, 🙂 

This is timely, as I need to re-acquaint myself with this for a project coming up. I worked with the APM product manager on the custom hierarchy ID enhancement for NY. I'll describe what we did, its working OK here, even with our upgrade to NY after loading the pre-release update set back then:

The hierarchy ID's are holding steady for us. I did:

- Property "use_business_capability_custom_hierarchy_id" set to "true".

- Job "Update Business Capability Levels and Hierarchy IDs" is set to Inactive.

With these set, I loaded capabilities, being careful not to create any circular references, or leave any numerical gaps in hierarchy ID's, since the update job is not used.

I've never run the update job, I was told by APM product management, once going down the path of custom hierarchy ID's with the property set to true, the job should be marked inactive, which I also interpreted as "do not run". I've never changed the root ID's or their Order (I made the order the same as root IDs, order only applies to root nodes). Typically an EA capability map hierarchy ID for root nodes does not change.

I think if you set the property to true, mark the job inactive, and refrain from running it (maybe inactivate the UI action for it to go along with the job), you should be OK.

-Jim

PS - Although, in testing the property=true just now in an Orlando personal dev instance, clicking the UI Action to run the job didn't change the hierarchy ID's, even when I put a numerical gap in them on purpose, whether or not the job is marked active or not, so maybe Orlando makes this all moot so long as the property is set to true. I didn't compare the Orlando code to NY in my pers dev instance to prove this, tho.