Gareth Cantrell

Is there anything that can be done to fix this? Maybe use a custom attribute on the user account for SAML? Those at least have 128 characters. There is definitely no way we can reconfigure over 3000 accounts just so their UPN's fit into 64 characters.

I think I found the issue. The setting app.itsm.progressiveCapture.newRequestFromEmail had no value, so the default IC "new request" was being used (and by default, I mean the setting: app.itsm.progressiveCapture.newRequest = "new request") This then did a switch capture to the "new service request" IC which in turn performed a switch capture to the IC configured to the catalog item. The IC for "new request" is "Co-worker search" -> "Request type details" -> "Select service" -> "branch on request type" -> switch capture (to "new service request" in this case) The IC for "new service request" is: "Co-worker search" -> "Select service" -> switch capture (to "IT - Service Request") The IC for "IT - Service Request" is: "Request details" -> "Attachments" I set the app.itsm.progressiveCapture.newRequestFromEmail setting to "new service request", bypassing the generic "new request" IC and now all is working as expected.

@James Ainsworth We've looked at the customer portal. Unfortunately, we will not be allowed to present that to any partners as it does not follow our approved guidelines for colour schemes and is not customisable (for example, all the service icons are a blue-ish colour). Additionally, all our partners are already part of our core SSO and already imported as basic users (as we could not have gone live without offering them support). Aside from that, having the ability to control widget visibility by group would also allow us to selectively show widgets to different groups of employees.

Something we would find very useful is the ability to have subscribers for portal widgets, in much the same way as we have for services. We have a number of 3rd parties who work with us and require access to our portal to raise requests and would like to only show specific information to these users. For example, we have a links widget which shows links to internal sites which ideally should be hidden from these users. We also have some "buttons" in a links widget which allows users to navigate to our Facilities and HR domains and would also like to restrict visibility of these. Having the option to subscribe certain groups of users would allow us to effectively hide widgets such as these from users not in the correct Company/Department/Group/etc.

@James Ainsworth thanks for your response. We don't have anything specified in that setting. What happens is when we click "+ Raise Request", we go through the default IC as mentioned, which asks us for the service and catalog item. Even after selecting this correctly (i.e. using exactly the same service & catalog item that is configured in our routing rule template), it is not attaching to the workflow specified in that catalog item.

We are automatically raising tickets from emails against a specific Service/Catalog item and this seems to work well when the system raises the ticket. However, we also have exceptions where tickets need to be manually raised from the "+ Raise Request" option and when we do this, against the exact same Service/Catalog item combination, an error is raised and the ticket shows in the "No Team Assigned" list and with no associated business process. As you can see from the below image, this was attempted 7 times resulting in 7 orphaned tickets: How do I go about understanding why this is happening, and more importantly, how to STOP this from happening? Thanks, Gareth

Thanks @Steve Giller and @James Ainsworth for the responses. @Steve Giller nailed it - it is the only service in our portfolio which is not available on the portal - I've made a mental note about this (and should probably document it somewhere)! Cheers, Gareth

Not sure if I've missed something .... I have a service request created by a team member from the Request List view, with themselves as the customer. When they go to the portal, it is not showing in any of the request lists widgets and if we use a direct URL to the ticket (eg. https://live.hornbill.com/instanceid/catalog/com.hornbill.servicemanager/request/SR0000xxxx/, an error message is displayed stating they do not have permission to view the request. Is there something I need to turn on for users to see their own requests in the portal if they are also full users? Thanks, Gareth

Thanks @Steve Giller Not sure how I missed that thread. I have updated our process and it works as expected.

Is there some way we could clear down sub-statuses when a ticket gets resolved? Currently, when a ticket gets resolved we are unable to change the sub-status in the BPM as we can only set sub-statuses on "active" or "on-hold" parent statuses. This is causing some confusion with our users and we'd like to figure out how to fix this. Thanks, Gareth

We have recently tried to synchronise all our users from Azure AD into Hornbill. However, Azure AD allows for a maximum UPN length of 113 characters (64 before the @ and 48 after) (see https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-sspr-policy#username-policies), however Hornbill restricts us to 64 in total. This has had the undesired effect of 725 of our user base not able to access our new portal as we cannot synchronise their accounts! At this point I'm not sure what our options are, as we cannot recreate core accounts for nearly 20% of our user base.

+1 Having just gone live, it is difficult to determine what is happening when our users tell us the notifications were not received as we cannot search these messages. Also, for general trouble-shooting, it would make life much easier.

@Gerry Thanks for the feedback! As Bob will attest to, I have been fixated on the business rules feature ever since I saw it in the roadmap, and it will hopefully allow me to retire my brand new Azure function apps before they get too old I am happy to hear about the addition of expressions to Webhooks. Cutting down on the extra logic I currently need in my scripts will make it easier for my colleagues to manage these (until the business rules feature drops).

@AlexTumber thanks for the update. I can appreciate that it'd be a major change and we can live with the workaround. On that note, it would be really nice to be able to attach conditions to a webhook, insofar as it would then only fire if those conditions are met. Currently, a single update can cause a webhook to initiate multiple calls, with varying information carried in each call.

+1 We currently stand to lose a LOT of contextual information about our services once we import them into Hornbill.

I have noticed that the update payload for Incidents (urn:webhook:entity:Incidents:updated) are not consistent with the other Request entities (ChangeRequests, Problems, Releases). For example, I have a webhook listening for updates to Change Requests and the webhook sends the h_fk_reference field in the record structure: { "onEntityEvent": { "eventSource": "urn:webhook:entity:ChangeRequests:updated", "callingSessionId": "U2023051500000957.5086", "eventTime": "2023-05-16 11:05:35Z", "actionBy": "xxx", "actionByName": "xxx", "entity": "ChangeRequests", "record": { "h_fk_reference": "CH00000234", "h_custom_a": "Medium", "h_last_updated": "2023-05-16 11:05:34" } } } However, when using Incidents, the webhook sends the h_pk_id only, so it is not possible to determine the request Id as the API doesn't appear to have any methods for retrieving the underlying request: { "onEntityEvent": { "eventSource": "urn:webhook:entity:Incidents:updated", "callingSessionId": "U2023051500000956.4189", "eventTime": "2023-05-16 10:28:40Z", "actionBy": "xxx", "actionByName": "xxx", "entity": "Incidents", "record": { "h_pk_id": "121", "h_custom_a": "Medium", "h_last_updated": "2023-05-16 10:28:40" } } } I can get around this by configuring the webhook to send a Requests:updated event, however this is inefficient and results in more outgoing calls than is necessary when I'm only interested in Incident updates. Is it therefore possible to update the Incidents payloads to include the h_fk_reference field, rather than the h_pk_id field?

+1

+1

+1 We have simple lists where we don't want alphabetical ordering, so we end up re-creating these in the IC and task forms so we can specify the order - this means keeping track of where all these are configured in the event we need to add an option. Having the ability to specify the default ordering in a simpleList would help immensely.

Hi @Gareth Watkins We created a custom role with the “Get Database Schema” system setting and assigned that to the users who need it