Email rules

[Dan Munns]

Hi all,

I am having difficulty getting the email rules to work this morning.

We have changed mailboxes and as such I need to create a rule as follows:

"If email is sent from <old address> and contains subject line <IT Request Form 2016> logOrUpdateServiceRequest"

However I cannot get the email rules to play ball today.

Any help gratefully received

Thanks

Dan

 

[Victor]

@Dan Munns can you post a screenshot of the rule configuration? (you can blank/delete/blur email addresses if you don't want them visible in the screenshot)

[Dan Munns]

Hi @Victor

Screen shot attached. It passes a regex tester in Python but not JavaScript but (unless I remove the / and then it passes both. I have tried both but neither work)

Probably something stupid I have done / not done.

Any danger of giving us email rules straight from the email view like in Outlook?? Haha.

 

[Victor]

@Dan Munns uhh...REGEX, always these takes soo much time to "decode" and "encode" properly  ... May I ask you try a simple SQL expression like:

subject LIKE '%IT Request Form 2015%' AND fromAddress = '<email>'

and see if this works? Then at least we know we have to look at that REGEX expression and is nothing else faulty...

[Dan Munns]

Hi @Victor

The above expression does work, so it is something horrible in mine (which I kind of gathered)

It will do what we need it to do as is for the moment.

I will just have to brush up on my regex (sigh)

Thanks

Dan

EDIT: Ok so I lied a little. Any call raised via an email and this rule fails the BPM with the following error:

64945	23/01/2017 14:26	error	comms	9012	Operation[apps/com.hornbill.servicemanager/Requests/bpmOperation:getCustomerInformation] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/getCustomerInformation): nodeName: Invoke Flowcode: shrGetCustomerDetails; nodeId: e660ce0b-abf4-4b1a-9239-1c4341c94f95; At 211/1: "Uncaught EspMethodCall:invoke: Operation[apps/com.hornbill.servicemanager:shrGetCustomerDetails] FlowCode Exception (com.hornbill.servicemanager/flowcode/fc_ops/shrGetCustomerDetails): Security failure" throw(e); _fc_node_exec_e660ce0b_abf4_4b1a_9239_1c4341c94f95
64944	23/01/2017 14:26	error	comms	9012	Operation[apps/com.hornbill.servicemanager/Requests/bpmOperation:getCustomerInformation] FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_bpm/getCustomerInformation): nodeName: Invoke Flowcode: shrGetCustomerDetails; nodeId: e660ce0b-abf4-4b1a-9239-1c4341c94f95; At 211/1: "Uncaught EspMethodCall:invoke: Operation[apps/com.hornbill.servicemanager:shrGetCustomerDetails] FlowCode Exception (com.hornbill.servicemanager/flowcode/fc_ops/shrGetCustomerDetails): Security failure" throw(e); _fc_node_exec_e660ce0b_abf4_4b1a_9239_1c4341c94f95
64943	23/01/2017 14:26	error	perf	9012	apps:getCustomerInformation() Operation Invocation results: failure (198443008 B, 1007 ms, 0 kB, 0 ms, 0 kB) Slow API response!!!
64933	23/01/2017 14:26	error	scripts	9012	nodeName: Invoke Flowcode: shrGetCustomerDetails; nodeId: e660ce0b-abf4-4b1a-9239-1c4341c94f95; At 211/1: "Uncaught EspMethodCall:invoke: Operation[apps/com.hornbill.servicemanager:shrGetCustomerDetails] FlowCode Exception (com.hornbill.servicemanager/flowcode/fc_ops/shrGetCustomerDetails): Security failure" throw(e); _fc_node_exec_e660ce0b_abf4_4b1a_9239_1c4341c94f95
64932	23/01/2017 14:26	error	comms	9012	Operation[apps/com.hornbill.servicemanager:shrGetCustomerDetails] FlowCode Exception (com.hornbill.servicemanager/flowcode/fc_ops/shrGetCustomerDetails): Security failure
64931	23/01/2017 14:26	error	comms	9012	Operation[apps/com.hornbill.servicemanager:shrGetCustomerDetails] FlowCode Exception (com.hornbill.servicemanager/flowcode/fc_ops/shrGetCustomerDetails): Security failure

The call is logged but wont progress any further

 

 

 

[Victor]

@Dan Munns I'm starting to hate this "Security failure" ... Another customer had/has same issue, can you follow the same advice and see if you still have the issue? (link below)
 

 

[Dan Munns]

Hi @Victor

Switching the setting mentioned in the linked thread worked and we are now no longer getting the error.

Thanks

Dan

[Victor]

@Dan Munns just to be aware, the setting in question is managing the BP spawn on logging requests. Basically if you have a complex BP, when it spawns on a new request, it will be a delay from when the analysts logs the request until it can access it (the delay is direct proportional with BP complexity). By complexity I mean the number of nodes the BP goes through until it expects an action from an analyst (like a "suspend" node). The async spawn setting would allow an analyst to open the request straight after it was logged and not waiting for the BP to fully initiate (this would happen in the background).

So, what I wanted to say is that, depending on your BPs complexity, you might experience these delays when an analyst logs new requests... if your BPs are not very complex, the delay should be barely noticeable...

[Dan Munns]

@Victor  Ok, is there going to be a fix for this at all?

Some of our BPMs go through quite a few automated nodes before they expect human input so could be an issue.

[Victor]

@Dan Munns we have an internal investigation into this, as it definitely affects the use of autoresponder in conjunction with async BP spawn. So I believe they will have this functionality re-written, however I'm afraid I don't have any ETA, but hopefully in the (very) near future...

[Dan Munns]

Ok thanks @Victor

[Dan Munns]

Hi @Victor

For some reason this rule has stopped working now.

No error messages just none of the emails are triggering a logged ticket.

Any ideas?

[Victor]

@Dan Munns is it possible that you don't have an analyst (co worker) or a contact with an email address that matches the originator/sender email address? If true, then in conjunction with (or based on) the below setting, the AR will not log a request.