CA Service Management

Hi everyone,

We have the 'convert' customization, where you can convert an incident to a request, or a request to an incident.  I am trying to make the maileater update rule for both objects accept either word in the email subject line (incident or request) to successfully update the ticket, because when the ticket is created as a request and converted to an incident, when the customer replies to the email they received, the subject line in that email says Request ##### and it doesn't update the ticket.  

The current filter string for updating incidents is:  Incident {{object_id}}

The current filter string for updating requests is:  Request {{object_id}}

It doesn't work to just create an additional rule that updates incidents with this filter string: Request {{object_id}}, because it fails on the first rule and doesn't go to the second one.  How can I have one filter string for an email subject line that could have either word?

Thanks,

Tammy

HI Tammy,  I dont think this will be possible because there is no combined trigger in the system to be able to update both (hence the customization needed to convert a ticket in the first place).   Based on the subject line the mailbox rule is interpreted by maileater as a literal - meaning it queries the cr table with either type=I or type=R in the where clause based on the mailbox rule settings.  There is no way to force a mailbox rule to look at multiple objects, as it just isnt built that way unfortunately.

Jon I.

Hi Jon,

Thanks for the reply -- but I'm not trying to make one mail rule update multiple objects.  I'm trying to make a mail rule accept multiple email subject lines --- either Request  {{object_id}}  or  Incident  {{object_id}}.

Hope that makes sense....

Thanks.

Tammy

Hi Tammy,

I totally understand what you mean, however, in that one mailbox rule, you can only choose one object to update, so it would either be request, OR incident, but not both. You cant set the rule to update both Incidents and Requests. There is no way for the rule to dynamically change what object its looking for and taking action on based on whats in the subject.

Jon I.

Tammy, they are regular expressions so may be you can try something like

[R|I][e|n][q|c][u|i][e|d][s|e][t|n][t] {{object_id}}

I didn't test this out but simply throw out here for your consideration based on my understanding. Thanks _Chi

Thanks, Chi....  I just tried that, but it didn't work..... 

Tammy, I am curious if the following one works:

[I-R][e-n][c-q][i-u][d-e][e-s][n-t]* {{object_id}}

Thanks _Chi

Chi - I dont think any of these will work because in the end, Tammy needs the rule to update either a request, OR an incident regardless of what is in the subject line.  For example, if the ticket was originally opened as a request, then converted to an incident, and an end user replies back to an email from when it was a request, they want it to update the incident.  But in the rule, you can only specify whether that particular rule updates requests, or whether it updates incidents.  There is no way for it to know whether its a request or whether its an incident without the subject line telling it that information. So I dont think this will work at all no matter what we try to set up as the keywords in the subject line.

Here is a screenshot of what I mean...the rule itself can only pick one object, either request, or incident, but not both:

So for the example, if a ticket was originally a request, and it got converted to an incident (by way of the customization that Tammy has in place), that ticket is now an Incident and no longer a request.  However, if the end user replies to an email that was from when the ticket was a request (before it was converted) and the subject has "request" in it, then the mailbox rule for that subject wouldnt work to update the ticket because it's action object is Request and not incident.

Is my thinking correct here?

Jon

Thanks, Chi --- but no, that didn't work either.  I am revising both of the rules when I test this (the one for incidents and the one for requests), but I think Jon is right because it doesn't skip through the first rule (since the type isn't right), and look for another rule that matches and the type is right.  If it did that, I think it would find the second one and update the ticket successfully.  It's a shame that it doesn't exhaust all rules first before declaring that it can't update the ticket.

Thanks,

Tammy

Tammy, I was thinking the same rule with multiple matching strings using some kind of regular expressions. And in your case, it seems you can consider 2 rules--one for incident type and one for request type-- and both rules have the same filter statements that work for either  "Incident {{object_id}}" or "Request {{object_id}}". That is, instead of 4 rules(2 for incidents and 2 for requests) you could use expression like this to make it to 2. Thanks _Chi

That's exactly what I did, Chi.... 2 rules, with the same filter, but updating different objects.  However, the system doesn't skip over the first one when it can't perform the update and go to the second one.  It fails on the first one because it can't update that object.   Sigh....

I totally understand the frustration, however please understand that what you are looking to do is not a typical case as we dont have the functionality out of the box to convert requests to incidents.  Typically the ticket type would remain the same, and so the fact that the subject changes or doesnt change, wouldnt matter - it has to do with the object selected on each rule.  The rules are there to look at the subject and act based on them, but they dont check the fields within the rule to match it to a ticket.  The rules are sequenced so that the most viable ones would be at the top of the list so they would be met first. 

I do understand your use case, and I can see how some folks would benefit from it.  If you want, you are certainly free to go ahead and post it as an idea here on the communities for folks to vote for it if they feel it would benefit them as well.

Thanks for understanding Tammy!

Jon I.

I do understand, Jon --- Its' not OOTB functionality.  And for an update, I guess it does need to decide to either 'update' or 'fail' on that rule, rather than looking for another one in the list that might work before deciding if it's a fail or not.

Thanks anyway!
Tammy

Now I got it...it is not the filter but the maileater will not read the rest if it matches one.

Both of you are right here...something currently can't be done.

@Tammy, it seems to me this is a good idea that you can submit...and I will vote for it.

I would, Chi -- but it seems that it would need to be changed to somehow exhaustively check all rules for an update rule that would work before deciding it can't do the update and failing.  I'm just not sure how it would be able to do that, since the failed response that is sent back is part of the rule....   Either that, or the idea is to allow the possibility of multiple object types to be updated within one rule...

Tammy

Hi Tammy,

So on this one I think we are all on the same page that this cant be done at this point.  Def. post the idea for this on the communities along with your use case if you have not done so already.  This way folks can vote for it

If you dont mind, please mark the most appropriate response as the correct answer on this one so we can close up the loop.

Thanks Tammy - have a great weekend!

Jon I.

Yep, just did, sorry.  Haven't had time to submit an idea for this though... Would you suggest that the idea be to allow the mail rules to update any object that it finds a match on, or just that they allow you to select multiple objects from the list?

Thanks.

Tammy

No worries!

I would post the idea with both options saying that either way would meet your needs

See what folks comment on it...