Suspend Await Expiry

[Janett Dervish]

Hi,

Please advise, I have a suspend await expiry node which is not working as expected, an email shoudl be sent after the case is closed, please advise how this can be resolved.

Thank you 

[Jeremy]

@Janett Dervish what do you have set for the times?

[Janett Dervish]

Hi Jeremy,

Please find screen shot below. 

[Jeremy]

@Janett Dervish So the end of the get timestamp node is the correct outcome chosen? As I have this in my test bpm:

&[global["UtilitiesGetTimestamp"]["timestamp"]]

[Janett Dervish]

Hi Jeremy,

I have updated the Timestamps and run a few tests but unfortunatly I'm still having the same issue, is there anything else I could be doing wrong.  Thank you 

Janett  

[Steven Boardman]

@Janett Dervish could you add a request > update request > timeline node after your cloud automation and inject the following into the text field using the variable picker

* Value from the Custom21 field

* Timestamp output from the cloud automation node

Then share this info

That will let us see what date/time values are in use as an initial check?

[James Ainsworth]

Hi Janett,

Is it possible that it is your decision node that is not working?  It could always be going straight to the end node (no match) and not going down the path for sending the email?  I'd be interested to see the conditions that you have set for Oyster use.

Regards,

James

[Janett Dervish]

Hi, I have added the additional nodes as advised and run a futher test please see screenshot. I have also uploaded a screenshot of the Oyster use Expression. 

Janett

 

 

[Steven Boardman]

@Janett Dervish looking at the screenshot, is the date/time generated from the Cloud Integration call the top post in your image?  if so this may help identify the issue, as it is showing

23:03 on the 25th

and the original date time is 00:00 on the 26th, so the utility is returning a value which is 3 minutes past 23:00, which is before the 00:00 on the 26th?  So looks like a timezone issue.

 

[Steven Boardman]

@Janett Dervish is the original date value, an answer to a progressive capture question or only a value you hold in a request custom field, if it is the former, you could try injecting the progressive capture date answer as the starting timestamp value, and see if this corrects your timezone issue - i.e puts the new timestamp in the future not the past

[Janett Dervish]

Thank you for all your advice, I changed the pro cap to include a Date & Time field, the Cloud Automation Node then worked accordingly and activated the Expiry Node properly.  When Testing I selected one hour in advance to take account for British Summer Time on the application entry, the process followed the correct timeframe also emails followed through at the correct time when taking BST into account.     

Kind regards

Janett