TBSM Event Identifiers - default BSM_Identity vs custom ones.

This is going to be a technical post.
TBSM is still quite powerful tool to track your service components availability and calculate your service outage durations and report on them.
One of the key elements to make it all happen is mapping events or KPIs on the service tree items.
There's a default mechanism for that, or rather a field called BSM_Identity.
I have made a finding that I wanted to share with you. It's not documented too well in the official documentation.
In short: BSM_Identity is event identifier. Name of field in event or SELECT statement that is expected to contain a value that will identify one and just one service instance in TBSM service tree. You can have one or more event identifiers (sometimes you need more same time in order to achieve uniqueness) and they can have other names than BSM_Identity, but BSM_Identity is the one which is default, as stated here:
http://www-01.ibm.com/support/knowledgecenter/SSSPFK_6.1.1.3/com.ibm.tivoli.itbsm.doc/customization/bsms_dlkc_id_rules.html
But how does it work in real life?
We do have to specify name of event identifiers in Incoming Status Rules. We basically can choose from all existing fields in alerts.status in case of ObjectServer being the data feed or all fields returned in SQL SELECT in a data fetcher or all fields returned via policy fetcher. There are no defaults. We have to choose one or more fields.
On another hand, if we integrate with TADDM or CMDBs via SCR API, we don't have to specify any name of a field in eventidentifiers artifacts if we don't want to. In such a case, by default their names will be BSM_Identity.
It means if we want to work with defaults, we can only achieve it if we ensure that we're:
a) adding BSM_Identity field to alerts.status table in ObjectServer,
b) using BSM_Identity alias SQL SELECT statements in data fetchers
c) using BSM_Identity as label in Impact DSA used in policy fetchers
Simple? ;)
I can post more examples if people are interested in it.