Custom event to send an email to the MRB coordinator IFS Cloud

Hi Mike 

First guess is that either the custom attribute has not correctly been made available to the Event Action from the Event configuration, the &NEW value for MRB_COORDINATOR has not been made available, or that it is working but the value of type “Person” for Comm ID “1” is not being returned turned as expected.

Check the Event configuration for the first two and check that the value being returned for that type for that Comm ID is as expected via direct DB queries.

You know your stuff so you’ve probably looked at these things already but perhaps this will help.

Cheers,

Nick

I’m also not sure whether the IFSAPP. prefix is necessary when defining custom attributes… you might want to try dropping that off if the other thoughts don’t help

No luck, but thanks. I’ll dig into this formula more.

Hope that all is well!

Hi ​@mfrejik,

Can you please give a try by creating another custom attribute with below getter function.

COMM_METHOD_API.Get_Default_Email( &NEW:MRB_COORDINATOR)

Please ensure Default per Method should be enabled for at least one email address.

May I know your email trigger point, is it triggered with creation of MRB case itself?

Hi ​@mfrejik,

As per Manage Event Actions:

"A Custom Defined Event can have Custom Defined Attributes. Enter a name for the parameter and a PL/SQL function <Package name>.<Method>. The PL/SQL function can use Attributes described above as arguments."

Example: Fnd_Role_API.Get_Description(&NEW:ROLE)

So, the approach itself is correct - a Custom Defined Attribute named CoordinatorEmail defined with a PL/SQL function, referenced as &CoordinatorEmail in the message body or To: field, is exactly the supported pattern.

The custom attribute appears to be calculating correctly, but the issue is likely with how event message substitution variables are resolved.

&CoordinatorEmail will only work if the custom attribute is exposed as an event substitution variable and is available in the event action context. Simply creating a custom attribute does not always make it available for use as a replacement variable in message recipients or message bodies.

A good first validation is to place &CoordinatorEmail in the message body and trigger the event. If the email body still shows the literal text &CoordinatorEmail, then the variable is not being resolved by the event framework. If it resolves to a value in the body but not in the recipient field, then the recipient field may not support custom attribute substitution.

Also verify that:

• MRB_COORDINATOR contains a valid person ID.
• COMM_METHOD_API.Get_Value('Person', ..., '1') returns the expected email address when tested directly in SQL.
• The custom attribute is marked as available for the event and appears in the list of event substitution variables.

For troubleshooting, I would recommend first checking whether the custom attribute value is actually generated in the event payload/log. If the value is present there but &CoordinatorEmail is not resolved, the limitation is likely within the Event Action substitution framework rather than the custom attribute itself.

A useful test would be to add &CoordinatorEmail and &NEW:MRB_COORDINATOR to the message body and compare the output. That will quickly show whether the custom attribute is being evaluated and exposed to the event action.