Victor

@Berto2002 has a solution for you here @Joy ...

@Dan Stewart I warmly recommend checking out our Hornbill Academy portal: https://academy.hornbill.com/. You'll find a wealth of valuable introductory and advanced courses there, including ones on automation and workflows. It's a fantastic resource to help you get up to speed with what's theoretically possible to build in Hornbill.

@Berto2002 I'm not sure who provided this advice (I tried searching in our instance, but my searching skills might not be the best), but the advice is not accurate. If this is a caching issue, it might explain why running the node with some delay could help, but it's not a real solution. I wouldn't suggest it as a workaround because it could lead to an unpredictable situation. I'm not exactly familiar with the issue you mentioned where you have a "raise new request" followed by "update the new request," and it's not updating the new request. If this is the case, I must stress that it's not about how nodes execute (sync/async). Delaying the update node might help in some cases (if caching plays a role here), but there's no guarantee, as you've seen the issue continue even after using what seems to be an incorrect "workaround." I would still recommend that Hornbill take a closer look to identify the root cause and a fix, assuming there's a confirmed defect.

@Berto2002 a fix for an issue is always good.

Will say this again and will bold it and underline it: Node execution within a workflow, a sequence of nodes execution, is synchronous. If there is an issue in a scenario where there is a raise new request node followed by an update the newly raised request, if the update does not happen, this is NOT because node execution order (e.g. because of asynchronous execution, this is not the case, the nodes execute synchronously). This can potentially be a caching issue, but is something that should be working, but it isn't, so something Hornbill needs to investigate and address. EDIT: the scenario where once a new request is raised, which has it's own workflow running, between the "old" request and "new" request, if both have running workflows, they will execute asynchronously because, in essence, they are different workfows so they will run asynchronously... so one would need to be aware of this apsect when designing the workflows for the "old" and "new" request.

Ok, I don't know who gave this advice, but it is incorrect. There seems to be a misconception enforced here where node execution in a workflow is asynchronous. This is incorrect. Node execution within a workflow is always synchronous, meaning if there is a Node B after a Node A, the node B will only execute once the node A execution completes. To put this in the example above, if a workflow has a "raise new request" node, the workflow execution past this node will continue once the new request has been raised and NOT while the request is being raised. The workflow nodes themselves can perform various actions that are themselves asynchronous (integration nodes/cloud automation nodes come to mind), but the nodes within a workflow, a sequence on fonde within a will execute synchronously.

It is going to be removed soon.

@Berto2002 that is development language... sometimes it does not make any sense, but to them... in layman's terms, it means "made drop down fields in captures a bit prettier to bring them in line with how pretty these fields are in other areas on Hornbill"

@Berto2002 if you don't want UTC values in the template, you can format them: https://docs.hornbill.com/servicemanager-config/customize/email-templates#field-formats-and-modifiers

@katy_palmer @Horn assuming you have the import set up specifically to query basic users, we can say this import is tailored for basic users. The users with additional roles you're mentioning are typically full users and shouldn't be affected by this particular import. However, it does depend on which users you query at the source. Ideally, these groups (basic/full) would be separated at the source, allowing you to design distinct imports for them, should you also wish to import full users.

@Kelvin when you're searching, where exactly is this search taking place? What specific area of Hornbill? Could you provide a bit more context?

@EllisW The ''REFERENCE NUMBER'' from an email subject mentioned in this post needs to be a Hornbill reference for the autoresponder to update a Hornbill request. Without the Hornbill reference in the email subject, the autoresponder can't update the request. There are alternative approaches to have what you need to be implemented in Hornbill (as Berto advised above).

Perhaps consider not having the user ID as "firstname.surname" in Hornbill if this is something you/your organisation wants to be kept up to date. Maybe some form of ID, for example, Azure/Entra has the GUID (User Object ID) attribute for users, something I have seen being used for user ID in Hornbill by other customers...

As I explained in this other thread, yes, it would make a difference if: the workflow sets the priority before the workflow starts the timer the SLA(s) are configured to set an SLA and a Service Level (SL) based on priority

Then I would suggest asking success@hornbill.com to see what options there are to have this configured for that mailbox