Victor

@derekgreen the rest of the affected request should now be fixed... These are the ones I found (15 of them enclosed below) which referred to the "old" service level ID. I hope these are the whole lot but if you find any that I might have missed please let me know IN00000969, IN00000978, IN00001162, IN00001187, IN00001202, IN00001226, IN00001257, IN00001266, IN00001270, IN00001271, IN00001281, IN00001284, IN00001290, IN00001299, IN00001303

@Rohit Govind I know !!! They should know better!!! ... I think on this occasion the requests are not at fault...nor the BP configuration... I ran some tests and I suspect the "Close after a period of time" action is not triggering the closure after 1 min (as configured)... I asked dev team if they have any thoughts as I suspect a defect at this point...

@SJEaton it does explain thanks, let me have a think ...

@derekgreen I threatened the instance that I know where it is hosted...what services it uses an so forth... fear works! I'll have a look and see (which/how) the rest of the affected request and apply the fix (if is the same issue, but it looks like it...)

@derekgreen right, I just had a word with your instance, the behavior is unacceptable! ... May I ask to give it another go... third time's the charm they say!

@derekgreen hmm... think I have missed something before... argh, you make me work...so much for my plan to slack all day ... can you try again?

@Rohit Govind thanks, I'll have a look and see if I can spot anything obvious why they failed to do as told!

@SJEaton hmm... interesting scenario you have there, I actually never thought of it before ... Your assumption is correct, you can't end the BP inside parallel processing... you don't necessarily have to have the decision node outside, but the end needs to be outside... What is the process trying to do, how you want it to work? Perhaps we can think of a way to achieve the desired workflow with the end node outside...

@derekgreen can you try and resolve IN00001274 (I assume you wanted to resolve this one) and let me know how it works? If all fine I will apply the same "fix" for the other 15-16 that have the issue...

@Rohit Govind setup looks correct and it should work as designed... do you have any recent examples (request references) where this failed?

@SJEaton no, there is no limit on how many parallel processes you can run at a time... (any that I am aware of, but certainly you can have more than 3...)

@derekgreen ah...alcohol...!! I read once that alcohol is really bad for your health... so I stopped reading since. I'll have a look to see if we can fix the existing requests, we might be able to change the ids but can't say for sure...might not work but we'll see.

The issue is that is trying to reference a service level ID which no longer exists... the inexistent ID is the P4 service level, and looking in the data, it seems a new P4 service level has been created at some point... If this is correct, there are 16 requests in active state which will throw the same error... Let me know if the scenario is correct so I can see if they can be fixed...

@derekgreen did you delete and recreate P4 service level in your "Service Desk" SLA? ... whilst this request was active? EDIT: btw, removing the node from the process is not related to this error...

@DougA it does not apply retroactively I'm afraid... so emails already in Inbox woudl have to be processed manually

@DougA incorrect definition of the expression in "test" rule: This is how it should be defined (if you're matching the string in the subject line):

@DougA I'm looking into this... btw, the mail logs won't tell you why the routing rules did not work I might be wrong on this one... *sigh

@Ralf Peters good to know the issue is fixed Maybe the mail server/service was restarted? I heard of similar issues before where sometimes a restart might cause issues with accounts... but don't quote me on this

@Ralf Peters can you confirm your IMAP server is up and running and nothing changed on the mail server (configuration, credentials, etc.)? The connection test fails for some reason, I've sent you the chilkat log in a PM...

@Keith we're looking into this now...

@nasimg no, is not related to SM build, the issue is not application specific and only affecting few instances. Your instance is not affected by the issue.

@Ralf Peters thanks for the update, we're investigating what else is affected...

We restored services to the affected instances. @Ralf Peters do you still have troubles with your instance?

@all we are currently investigating this.

@Tina.Lapere the notes from the "top release" are the notes for the latest update... there seems to be a mistake in the title... it says build 944 but those are the notes from 954...same with the next, it says build 935 but those are the notes from 944...etc. I've asked dev team to have a look.