Service Desk Practitioners Forum

SD 5.0 Database Rules not always firing

Thorfinn Thomas
Super Contributor.

SD 5.0 Database Rules not always firing

Hi Everyone.
Sorry about the long post.

We have made a solution to send simple emails to caller of a servicecall and have the email logged in the servicecall, by also sending a copy back to the service desk server that adds a history line containing the email text.

This is done with 4 custom fields and 2 DB rules:
2 text fields for email subject and email body, one boolean field called "SendEmail", and one hidden (control)field called "EmailHasBeenSent".

First database rule that sends the emails works fine, it sends 2 separate mails (to caller and to SD server), and sets EmailHasBeenSent=True (Checked and verified).

Second rule works fine for the first email. It sets all 4 custome fields=empty.

When I send a second email, all seems to work fine again, EmailHasBeenSent is been set to true once again. But second rule that should clear the email fields is not firing / not clearing the fields.

Second database rule goes like this:
"When service call is created or modified
where EmailHasBeenSent (*) equals Yes
Delete Email Fields (Update Data) Email Subject set to (Make empty); Email Message set to (Make empty);SendEmail set to (Make empty); EmailHasBeenSent set to (Make empty)"

The condition that checks EmailHasBeenSent has "Evaluate this rule for this field" checked. But the field HAS been altered - both times, so it should fire the second time (I thought).

Any ideas why it doesn't work second time?

Best regards,
Ruth Porter
Acclaimed Contributor.

Re: SD 5.0 Database Rules not always firing

Hi Thorfinn,

Is the field EmailHasBeenSent a boolean?

If so try using a text or code field instead - I have seen issues with booleans.

Regards, Ruth
Thorfinn Thomas
Super Contributor.

Re: SD 5.0 Database Rules not always firing

Hi Ruth

Thanks for reply.
Good suggestion, but unfortunately it didn't help.
I think I have found a reason, by the errors I get in the log: "error: Object cannot be saved,because another user has changed it after you opened it. "

I will try to delay the firing of the rules by 10 seconds to see if that helps.

Btw, is there any way to force the DB rules to take prescedence over user changes in such circumstances?

Outstanding Contributor.

Re: SD 5.0 Database Rules not always firing

Hey Thorfinn,

Do you have any rules that wait a while and then fire? For example, we have a rule that moves tickets from a status X to Y after being in X for 7 days. That makes the list of rule instances in the thousands of records. HP flat out told us we have too many business rules (even though their consultants set them all up for us) in the rule instance queue at once.

I only bring this up because we're now experiencing catastrophic rule failures across the board. They keep telling us there's too many rules "on hold" at any given time.

We're in the process of turning as many business rules as we can into scheduled database jobs. (can you see me rolling my eyes yet)

Anyway.. just something to look into.
Thorfinn Thomas
Super Contributor.

Re: SD 5.0 Database Rules not always firing

Hi -=R=-

Yes, I am aware of this possible problem, and I am trying to keep the number of scheduled jobs down to a minimum.

We have at all times at least 300-400 Scheduled Rule Tasks awaiting firing time.

The lack of complex logic within the rules makes it necessary to have this many rule tasks scheduled.

I have been wondering about these scheduled tasks as a cause myself. But our use is not bgi enough to cause overload, I think.
The one thing I can think of is not workload related, but the fact that if some other DB rule fires and modifies some attribute after I have scheduled the cleanup task, the wrong attribute will be marked as "modified last" (or whatever the "evaluate this rule for this field" checkbox makes the rule verify against), and thus the rule might not fire.

Or similar; when the email for History update returns and updates the call, it will also change which attribute was last updated.

Anyway, converting into scheduled DB jobs seems a nightmare that I hope we will stay clear of, although I see the possible benefits, performance-wise.

Best regards,