Victor

@TonyOb can you give me one or two examples of requests logged or assigned where the notification was sent to an incorrect team?

@TonyOb can you please clarify the notification are about requests (tickets) assigned to analysts or tasks (activities within requests/tickets)? The screenshot suggests the issue occurs with tasks/activities but your description of the issue suggests otherwise...

@Prathmesh Patel still on my "to do" list... was very busy lately... ... I'll try and see if I can put something up today...

@Prathmesh Patel in this case, if you choose to disable the settings, I would suggest to disable both settings... in case you did not already do so

@Prathmesh Patel ah, I see... are you referring to the "routing rule" setting posted in the screenshot? Or "routing rules" all together, as a functionality?

@ALL We are still looking into this internally. This issue occurs if the source message transfer agent (MTA) didn't append the expected CR-LF combination to the end of the message. MTA in this case is Hornbill.(https://support.microsoft.com/en-us/help/2998901/-smtpsent.barelinefeedsareillegal-ndr-received-by-exchange-online-or-eop-users-in-office-365-dedicated-itar) Having an email message with lines ending with only LF would not cause any problems until Office 365 is configured to reject bare line feeds. From research done by @Martyn Houghton and our platform team we suggest this possible workaround: If the sender cannot correct the sent messages, or if the gap must be bridged until the message format is corrected, the recipient can create an inbound transport rule to append a disclaimer to the messages from the problematic sender (this being us, Hornbill). The disclaimer will append the expected CR-LF combination to the message so that it can be delivered. (This disclaimer may consist of a single character such as a period or a dash.

@Prathmesh Patel : we're happy this is sorted then As a reference note, there is no current functionality to allow you to add or amend a service on a request... It could be done by amending teh request record but this is something we reluctant to advise as it would require changes in the database directly... How did you add the service on that request?

@Awalker you would also need to make the custom field available in the request details section.... using form designer...

@Prathmesh Patel the "apply email to request" action fails when it's checking sub statuses associated to service and request type for IN*19477. This because this incident doesn't have a service associated to it. Also it seems you have these settings enabled: Automated Sub-statuses won't work with requests with no service... EDIT: also the email is not removed from mailbox because the "apply email to request" action fails at the above mentioned point and the email "removing" should happen afterwards...

@Stephen Hutchinson we are now looking to find the root cause for this issue. In @Martyn Houghton case we are now looking at email templates after we ruled out any interference from a 3rd party software. @Stephen Hutchinson do you have any 3rd party software that inserts something into an outgoing email? (like AV disclaimer or security appliances). These are also known to insert bare linefeeds into email messages.

@Awalker you are using a Suspend Change node on a Release request type... You would need to change the "Suspend Change" node to use the "Release" entity instead of "Change" entity...

@Martyn Houghton did you have a chance to test the template we amended yesterday?

@Paul Alexander yes it helps... I thought the same, that is something to do with copying the group...I think it worked, in the way that it was copied but it was not visible...something like this...the problem is that if this happens the BP becomes corrupted and it can only be fixed by manually removing the group from the BP definition...something not very user friendly...

@Paul Alexander hmm... I have to run a few tests as well... Is the "corrected" process working now?

@Gary@ADL yes, it was fixed in our latest SM update.

@Paul Alexander something really odd happened with this one... not sure how it got corrupted... did you copy anything, any nodes, from VINCI Leavers Process? (it seems like the whole Leaver Tasks group got copied into this one...) Anyway, since you need it ASAP, I have fixed it and the valid process is available under: "VINCI Contractor Moving/Leaving Process (Hornbill)" BP. You can remove the bad/corrupted one(s) - I have a copy - and rename this one to suit your needs...

@Paul Alexander name of the BP please?

@Paul Alexander I don't think the fix will be available until next update ...

@Paul Alexander it's a defect in logRequest flowcode when using linked requests (e.g. raise a child request from a parent request). Is being investigated...

@Sonali what is the request reference where you noticed this issue?

@David Calder it does help, thank you!

@DeadMeatGF I think with the "System Timeline Update" set to Auto (as in @Sonali example above) will create a timeline entry... The issue is as far as I understand at this point is that the action itself to set the category, is not working ... (this includes the timeline update too). I'll have a look and see what's going on.. .

@Paul Alexander Custom fields are limited to 255 characters. No global settings, so unfortunately you would have to limit the input using a REGEX function for these fields in ProCap. This ^(.|[\r\n]){0,255}$ or ^[\S\s]{0,255}$ should work. Not that I am aware of...

For future reference, the issue was caused by a Hornbill defect in which ProCap custom fields using static checkbox/dropdown boxes which are mapped to a custom field in requests table, would not populate the selected value in the designated/mapped custom field. Fixed in latest Service Manager update.

@nasimg 979. There is a typo in the changes section.