x Want to participate? Join the group to interact
  • State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 77 subscribers
  • Views 1560 views
  • Users 0 members are here
Browse Forums
Announcements
106
topics
32
replies
General Discussion
6k
topics
18k
replies
AlisonA

Send E-mail Escalation Rule - Suppress Repetition with Escalation Table

SUGGESTED
Posted By

Within an Escalation rule when using an onscreen notifications action it is possible to manage the dismissal of that notifications via the Escalation table.  If the Column within the onscreen notification is set to Escl_DateTime then for every onscreen notification an entry is added to the Escalations table.  When the notification is dismissed this field is updated to null and the onscreen notification for that particular record no longer appears.

When sending an email via an escalation rule by default there is no restriction on the number of times an email is sent for a particular record.  So if the SQL clause is something like the below

Orde_Status = 'Active'

Then every time the escalation service runs an email is sent for each active order, regadless as to whether or not an email has already been sent for that order.   Is it possible to use the Esclations table so that an email is sent only once per order? 

Something I have tried is to create a second action within my escalation rule which is a Set Column Value to update the Column Escl_DateTime.  However when the rule is run there are no entries added to the Escalation table so I cannot determine whether or not an email for a record has already been sent.

I am aware that there are two workarounds to this, but neither really fit my needs.

  1. Entity Level Notifications - These would be great apart from the fact that you cannot us a dynamic criteria.  For example it is not possible (as far as I am aware) to set a criteria which says list orders updated in the last 7 days, it is only possible to use a static date.
  2. Add A Custom field which is updated when the escalation rule runs - This works (and I have used it in the past) but this is a messy thing to do, especially when there are multiple escalation rules.  Adding numerious fields just to determine whether or not an email has been sent is a little excessive, should this not be trackable within the escalations functionality.

In addition I have also struggled to see how exactly the escalations work.  Is the escalation table only updatable by an onscreen notification rule?  Can an entry in this table only be made from the onscreen notification?  Also, when exactly is the entry added to the Escalations table?  For instance when an opportunity is created an entry is also added to the Escalations table as soon as the opportunity is saved.  Running a SQL trace an insert clause is run directly against the Escalations table rather than the view as specified within the rule itself.

Parents
  • 0

    You're right, you would need to use option 2. If you look at 'Email Reminder' then you can see it uses a 'stop' field as I call it. a text field that is populated once an email is sent.

    Now if you're creating multiple escalations that follow a process, rather than create multiple fields you could create one. So the first escalation fires off if the field is null.... then auto populates it with 1 (but only looks for null). The second escalation only fires if there is a 1 in the field and when it fires it put a 2 in the field (but only fires if there is a 1 in the field and not null) and so on. This way you can build up a chain of escalations 

    e.g. a Contract expiry date to fire off emails to the account manager at 6 months, 3 months, 1 month and finally on the day. 

    You could even put in a SQL trigger or escalation to null the field in certain situations in order to 'reset' the notification checks. 

Reply
  • 0

    You're right, you would need to use option 2. If you look at 'Email Reminder' then you can see it uses a 'stop' field as I call it. a text field that is populated once an email is sent.

    Now if you're creating multiple escalations that follow a process, rather than create multiple fields you could create one. So the first escalation fires off if the field is null.... then auto populates it with 1 (but only looks for null). The second escalation only fires if there is a 1 in the field and when it fires it put a 2 in the field (but only fires if there is a 1 in the field and not null) and so on. This way you can build up a chain of escalations 

    e.g. a Contract expiry date to fire off emails to the account manager at 6 months, 3 months, 1 month and finally on the day. 

    You could even put in a SQL trigger or escalation to null the field in certain situations in order to 'reset' the notification checks. 

Children
  • 0 in reply to Matthew Shaw
    There is an issue with using sequential numbers in that it assumes the escalation rules will fire off in a specific sequence, which is not always the case.  An single integer field could be used with bit masking, so for instance
    Escalation 1 = 1 (0001)
    Escalation 2 = 2 (0010)
    Escalation 3 = 4 (0100)
    Escalation 4 = 8 (1000)
    If the value where say 6 (0110) then you could see that escalations 2 and 3 had run.  If 4 then ran then the value would be 14.  However this does start to get a little cumbersome to implement.
    What I don't understand is how the built in notifications handle this as an entity level email notification can be created and it sends emails only once.

*Community Hub is the new name for Sage City