Victor

@Hiten via GIPHY

You need to look at the intelligent capture configuration used for raising requests from emails and Service Requests. This might very well be different than the capture used for same action but Incidents and might be different from the one used for "Raise New" in request list. First identify which capture initiates when using "Raise Request" when viewing an email. The capture used here is configured in app.itsm.progressiveCapture.newRequestFromEmail app setting. If this setting does not have a value then the capture used will be the one set on app.itsm.progressiveCapture.newRequest. See what capture is configured them look at its configuration and see if you can find why when raising Service Requests from emails don't give you the option to progress past services list...

@Stefania Tarantino it is definitely a template that has been changed from the standard default... it is possible the summary/description are supposed to be in an ESP condition but maybe something has broken that... for example, these conditions can easily break if the template is copied, pasted somewhere else (e.g. Word or other editor) where is reformatted and such, then pasted back... unfortunately I can't say from a screenshot, if you think the template is set up correctly but still not working properly then we can have a look via a support request.

@Stefania Tarantino we cannot troubleshoot the issue you are reporting based on the description alone, we need to look at some examples of the issue so a support request would be needed.

@Stefania Tarantino This is dictated by guest.app.requests.notification.notificationType.assignmentTeam app setting. It is enabled by default. Disabling it will stop notifications sent to the team. Assuming you are talking about email notifications then this is dictated by guest.app.requests.notification.emailTemplate.groupAssignment app setting. The default value is "TeamAssignmentNotification" and can be changed to a different value representing an email template that exists in your instance. This is a default template, it means it exists in every instance when the instance is created by Hornbill. It can be amended, reconfigured as needed. If you like to understand more about notifications in general, including the notifications for request assignment please review: https://wiki.hornbill.com/index.php?title=Service_Manager_Notification_Settings It is possible the values for summary and description have been configured to use ESP conditions for when the summary and description variables have no value. We can't say if and how without looking at how the template is configured. It can be that the email is triggered before the request has summary and description hence the variables will have no value. If the template is using ESP conditions, it can also be the condition is not configured as needed. We can't say if and how without looking at how the template is configured. If the text is configured based on ESP conditions, is not just simply deleting the "incorrect" text. The condition needs to be reviewed to understand why the text appears when it is believed it should not. What exactly you're asking when you say if something has changed?

@Dave Longley this is not currently possible in that area.

@JanS2000 yes, would help keep a better track for where we are with this. We did raise this with development and a support request should bring more attention to this.

@Paul Alexander so there are a few things here that, perhaps, could use some clarification. The asset data you have in your instance is incorrect as the database value for Used By is missing the user type part. This is due to import data which did not have this value at the time of the import. This needs to be rectified by adding this value in the import data. While the values stored in Used By filed did not cause a problem in the UI, now there are additional checks in place that validate the format and in case of an incorrect one will not display the information. In other words, this was an oversight in the system (which was now corrected) but unfortunately this affected the values you currently have which are no longer displayed. The solution here is, again, to correct the values for the respective fields. We have identified a defect whereby different letter cases in the user name will not be correctly parsed by the system leading to no values displayed in the Used By fields. This will be corrected shortly. There is also the aspect of the import mechanism allowing incorrect URN (the format we use in these fields) to be stored in the database. We are discussing this with our development team so additional checks are implemented for the import mechanism to avoid this scenario going forward (prevent incorrect values to be stored in the DB).

@AKetteringham I meant basic as in Microsoft basic (which does not work anymore), which in Hornbill would be classic. Here is some info, including troubleshooting that might be helpful: https://wiki.hornbill.com/index.php?title=How_to_configure_OAuth2_Authentication_for_Microsoft_Office_365_Mailbox_integration https://wiki.hornbill.com/index.php?title=How_would_the_Office365_administrator_approve_permission_requests https://wiki.hornbill.com/index.php?title=Troubleshooting_issues_occurring_during_the_setup_process

@AKetteringham MS Outlook is an email client so unless you have forward rules for the email accounts set in Outlook you won’t receive emails in Hornbill via Outlook. Hornbill mail service is also an email client. Unless I am missing something, what happens over there is that you could use (or so used) Outlook client to receive and send emails via the O365 account. You (also) have a Hornbill mailbox configured to receive and send emails using the O365 account. So in summary, there is nothing to revert to and almost certainly there is no “reverting to MS Outlook” in this scenario. Would be worth checking (test) the email connectors configured in Hornbill admin. Also, if you have not switched to oAuth authentication for the email connectors you would need to do so as basic authentication is no longer supported by Microsoft.

@Berto2002 at the moment the KE has been accepted and in progress. I do not have any other information on this at this time I'm afraid.

@Berto2002 the scenario you described has been identified as a product defect which is in development queue, ref: KE00174035. Any SLA re-evaluation will "reset" the response timer data (for response timers that were already marked) with incorrect values.

@JanS2000 please have a look on our wiki documentation (link below) and let me know if you have any queries after: https://wiki.hornbill.com/index.php?title=Request_Sub-statuses

@JanS2000 it is possible you have configured sub-statuses but you do not have set up these for both active and on-hold main statuses... from what I see in the screenshot it is possible the system is looking for (another) active sub-status or an on-hold sub-status but it can't find any...

@Berto2002 on all the above requests, is the SLA recalculated after the response timer is stopped? Can be in any form, manually, using the Re-evaluate SL workflow node or automated (based on criteria defined in SLA rules)?

@Berto2002 for routing rules there are 2 FAQs or guidance sheets as you call them: Routing rules do not process emails :: This is for scenarios where the routing rules simply does not process the email. The email lands in Inbox. This focuses on the potential issues with building rule expressions. Routing rules do not raise requests from emails or apply emails to requests :: This is for scenarios where routing rule do process the email but fail to preform the designated action. The email lands in the designated folder for failures on the rule that processed the email. Both FAQs are listed in this sub-section of Service Manager area: https://community.hornbill.com/forum/147-faqs-common-issues-tips-tricks/

@Berto2002 before raising a support request, can you please double check if the sender email address only exists once in the system?

@Damian Roberts if the user enters an incorrect password a number of times specified in the security.user.lockout.failedLoginAttempts.threshold system setting their account is suspended (locked) for the duration specified in the security.user.lockout.duration (minutes) system setting. If the security.user.lockout.type is set to "permanent" the account/user is suspended indefinitely and must be actioned manually if it needs to be re-activated.

@Damian Roberts there is no restriction nor limit (before a user is suspended) on how many times users can input their userid/password correctly.

@Salma Sarwar yes, request sub-statuses provide this functionality https://wiki.hornbill.com/index.php?title=Request_Sub-statuses

@Berto2002 indeed, it was advised before, as a possibility: However your solution is a bit less efficient, you don't need the 2-hour (or any delay), which means you create and trigger unnecessary events. With the above, you can have the main workflow resume only and when each linked request has been completed.

@Berto2002 support request and send us the report definition file please

Assuming functions.getTaskAnswers("task-8e8b6c91").field_1 has a value then you need a Get Request Details before outputting to timeline to refresh the workflow context data (variable values) after the custom field update. Mind you, the workflow is not using the data directly from the database it has it's own "cache" system (so to speak) which needs to be refreshed (e.g. with a Get Request Details) if the underlying data is changed (e.g. a custom field on a request is updated)

For future reference, the scenario with the sender email address being associated with more than one user or contact is covered in the FAQ document that was mentioned above. We kindly advise anyone experiencing issues with routing rules, new or existing issues, to review this document to ensure the issue is not caused by one of the documented scenarios.