CA Service Management

I am trying to build a notification to be sent to the contacts listed under a CIs Other Contacts. I am using the object contact 'CI's Other Contacts' in my notification rule; however the Primary Contact also receives the notification. How can build my rule so that only the Other Contacts receive the notification? It's behaving as if Primary Contact is embedded in Other Contacts, when there is a separate object contact for 'CI's Primary Contact'. Given this, I would think that Other Contacts should only include the contacts listed under Other Contacts. Does anyone have any recommendation on how to accomplish this? Any help is appreciated, thanks.

I'm sorry to say that, but I don't think that this can be easily done. There are some reasons for it:

• normaly, each notification recipient is a single contact.
• Recipients are defined by the "Object Contact Notification" records.
• These records include an "Object Attribute Name" which points to a contact srel from within the notification context.
• Normaly, there is something like "customer" or "assignee.vendor.primary_contact_uuid" as the "Object Attribute Name".
• In the case of "CI's other contacts", we found "@ci_other_cnt" as the ""Object Attribute Name".
• The @ sign tells the system, that it has to handle a special case here. Instead pointing to a single contact record, the system knows that @ci_other_cnt stands for the "list of contacts of a CI". This knowledge about the keyword @ci_other_cnt and "the list of contacts of a CI" is hardcoded in the system and connot be changed.
• This "list of contacts of a CI" is stored in a secific table (lrel_cenv_cntref).
• And now comes the real reason: Whenever you enter a primary contact to a CI, this contact gets automatically added to the "list of contacts of this CI".
• The GUI filters the "list of contacts", so it does not display the primary contact in the visualized list, because he is displayed in the "Primary Contact" field anyway, but nevertheless, the contact is part of the list.
• This is the reason, that the primary contact is also notified, when you notify "CI's other contacts".

The only chance I would see is by removing the logic of adding the primary contact to this list automaticaly. But this would lead to some other side effects, for example, if your contact is the primary contact of a CI, and you choose this contact in the Quick Profile, you would not see this CI in the Environment list of this contact.

Kind regards

.............Michael

Thank you for the detailed explanation. I was curious about the “removing the logic” option, not so much from your suggestion, but from a different approach. There are 2 things causing us issues, the Primary Contact added to the Other Contacts and the use of a Group as one of the Other Contacts. We added the Group so we could leverage the Groups environment to easily see all the CIs assigned to the Group. We only want the user contacts listed as Other Contacts to receive the notification, not the Group. Could the “logic” be modified to ignore the Group when sending the notification?

I think, whatever is in the "Other Contacts" list of a CI will be notified, when using the "CI's other contacts" recepient. There is no way to influence this or making exceptions, at least to my knowledge.

Hmm, not sure about why or in which circumstances you need to view the group environment and what is the reason that this is helpful....

Within the SDM analyst interface it’s beneficial for analysts to see all the CIs supported by a group by viewing the Environment of that group. This helps with ticket assignment, CI accountability and reporting. At this point we have accepted that what we want to do is not possible in the application, unless we remove the group from the CI’s Other Contacts. Given this we are looking at alternative options to deliver the notification outside of Service Desk.

Michael_Mueller

cdtj

Gutis

I understood your explanation but I have a question. I need to notify only the associated "analysts" like other CI contacts. It's possible?

Why you can't do it manually? HTML Notifications in a context of custom object.  

Because I need to create a notification rule associated with a specific activity that will send an email only to analysts and not clients. I thought about creating a QREL / BREL attribute on the 'nr' object that would associate these other CI users to reference this field later in an object contact. But I do not know if that would work.

You can add trigger on this specific activity, then run spel code that will iterate thought the contacts, and send notification using notify_contact method to the contacts that represents clients.

It is true. But it is exactly that solution that I would like to avoid because I will have to ignore the native notification process of the tool and trigger the notifications manually through Spel. And this is not good.

Hi Daniel.

The notifcation process first collects all persids of all contacts to be notified for each notification rule.

It then loops through all persids found and calls the method "notify_contact" for each.

If I understand you correctly, you want to notify only the contacts of type "Analyst" of the @ci_other_cnt list of contacts.

That means you would need to influence the persid collection procedure .

As far as I am aware, this is not possible. The interpreting algorythm of the "@" attributes is hardcoded in the domsrvr binary. That also means , you are not able to invent new "@" attributes, which might use a specific whereclause to get a list of contact persids.

Nevertheless, you might be able to Instrument different capabilities like specific notification methods, or specific contacts to achieve our goal.

Just as an idea: Add a specific contact to be notified in your notfication rule, provide a specific notification method for this contact, which executes your own program/script, which then collects all contacts you want to notify , and then notifies them contact by contact.

Best Regards

.............Michael

I understood Michael. But I think the solution of creating specific notification methods that would identify the type of contact would not be a good choice because in some cases these "client" users would need to be notified by some other notification rule. Unfortunately I realized that the "@" attributes were set internally and can not be modified. For this reason I am only considering two possible solutions: 1) Create a BREL / QREL attribute on the nr object by filtering only the contacts of type analyst; 2) Create a notification trigger that simulates the operation of the notification rule. Thanks for listening.

Hi Daniel.

How about an idea for creating Support for QREL/BREL attributes as a notifcation target.

Of corse nested qrel/brels should be supported as well.

So something like "asset.cntref.cnt" in a chg context would be supported. Additionaly, that would make these  hardcoded "@" references obsolete.

And you would be able to create your own QREL's/BREL's to support customer specific needs.

I'd vote for that!!

Best Regards

................Michael

I'll try this. Thanks.

Notification rules with object contacts linked to attributes BREL / LREL 

My solution for while:

MODIFY FACTORY lrel_cenv_cntref {
    STANDARD_LISTS {
          SORT_BY "cnt=cnt.last_name+cnt.first_name+cnt.middle_name, nr=nr.name";
          WHERE "cnt.type = 2307";
          MLIST OFF;
          RLIST OFF;
    };
};