How to access the notification record itself within the "Advanced Condition" Script field of the Notification record

[Bastian Pawlik]

Hi folks,

I've a little odd question but I was wondering if there is any posibility to access by script the Notification [sysevent_email_action] record from within the "Advanced Condition" field of the notification.

I want to retrieve the sys_id of the notification record itself and want to make it part of the condition to check wheather or not a notification should be send out.

I know that creating Events is the normal way of how to determine if a notification should be send or not.

But in my case there could be dozens of new notifications that should be able to be send out by script, it could be long-winded to create an event for each and every new mail.

It would be easier for example to only create one event that each of those notifications are listening to. And in addition the sys_id of the actual notification will be passed over as an event parameter. Then the only thing we need to check in the Advanced Condition field is, if the passed over sys_id matches the notification record or not.

Unfortunately I don't know if the notification record is accessible.

I was hoping that maybe "template" was the object I was looking for, but unfortunately it is only available at the "What it will contain" section, and not in the "When to send" Advanced Condition.

Maybe someone of you could give me a hint.

Alternatively I would be totally happy if there is any scriptable way to send out a mail based on a notification record without using the eventQueue.

Thanks and regards,

Basti

[snowtech1]

I may be wrong.

You could give a try to 'currrent.sys_id==${event.parm1}'   in the condition field.

[Bastian Pawlik]

Hi snowtech1,

thanks for your answer. Unfortunately the "current" object cannot be used.

"current" will refer to the current record of the table the notification should run against (like an incident record).

Best regards,

Basti

[Chuck Tomasi]

Hi Bastian,

Two things. First, I don't know of a way to reference the record inside the condition. It seems odd that if you trigger an event that says "Go start launching all notifications that react to this event" and they all (? perhaps most, some?) say "If this is me, don't run" then those ones will never run. How would they ever get triggered.

Second, hard coding sys_ids leads to maintenance issues. They aren't exactly "user friendly" so I recommend avoiding them when ever possible.

If you give us a bit more background on what your objective/use case is, we can help you come up with a creative solution. Why are you triggering so many events for notification? Why do you care if lots of events are being triggered? We have some business rules that can potentially trigger dozens of notifications all over the place.

Thanks

[Bastian Pawlik]

Hi Chuck,

thanks for the reply!

Here are some background information regarding my question:

The situation at our customers site is that he has lots of data (1Mio.+ user records, 1000+ active groups, etc.)

He wants to have the data to be as tight as possible. Therefore he is requesting something like a "Data Lifecycle Engine" where he can define within an application certain types of rules and actions to keep his tables as clean as possible.

Here are some usecases he wants to implement and maintain by himself (without knowledge of the underlaying table structure)- automatic removal of inactive users from groups that are longer inactive than X days
- annual mailings to group owners that only have up to one member in its group
- annual mailings to group members that they will be automatically removed from group after X days if they did not react

- ...

The engine itself for creating and maintaining such templates with the underlying table structure and instanciation of those templates are already in place. The customer wants to manage by it's own at what period of time which notification/reminder shall go out and maybe add another reminder to the template.

That's why I'm asking for direct triggering a notification by script. Because from engine stanpoint it would be the best if the maintainer of such a template can define that on a certain step Notification x (reference to notification record) should go out. In this case we have the sys_id of the notification that somehow needs to be triggered then.

Best regards,

Basti