In theory, by using action triggers, staff can review all past or pending notifications in a single, consistent place in the client, without having to ask a system administrator.
You can also disable notifications, if necessary, by disabling the action_trigger_runner.pl --run-pending action as appropriate. This can be useful if you need to take your mail system offline temporarily, or if you have a test environment where you don't want notifications to go out. This is harder to control when EG sends emails without going through the a/t system.
At Sitka we have literally hundreds of SendEmail a/t's and we run pending events on them every 2 minutes without any trouble. That's close enough to instant for our purposes.
In theory, by using action triggers, staff can review all past or pending notifications in a single, consistent place in the client, without having to ask a system administrator.
You can also disable notifications, if necessary, by disabling the action_ trigger_ runner. pl --run-pending action as appropriate. This can be useful if you need to take your mail system offline temporarily, or if you have a test environment where you don't want notifications to go out. This is harder to control when EG sends emails without going through the a/t system.
At Sitka we have literally hundreds of SendEmail a/t's and we run pending events on them every 2 minutes without any trouble. That's close enough to instant for our purposes.