AKJ

Thanks, I think this is what we had done previously so interesting to see this is the preferred method of sending a reminder, at least for the time being.

We are sending a couple of external email authorisation nodes with an expiry time of 14 days, with a reminder email to be sent 7 days after raising the call. Sending the reminder email should only occur if there is no reply to the authorisation nodes, which we're happy works well. These occur via parallel processing. It is the method we are using to count to 7 days to send the reminder email that is proving to be the problem. We've since tried 'Wait for Custom Field' for 7 days which should trigger once both emails are replied to instead of await expiry, but this too didn't work until we posted to the call's timeline or assigned it to someone. If the reminder section of this parallel process can't move on, the process will be effectively stuck until someone interacts with it. We are implementing a temporary workaround of requiring our Service Desk to assign the call to someone, in order to kick the first suspend node into gear and at least have the process working. We are curious as to what other nodes and solutions we could employ for this, as it sounds very much like we should avoid using the automation node Service Manager > Entity > Requests > Suspend as much as possible!

We've just made live several new processes as part of a new directorate landing page, but we had to pull one process at the last minute as we think a bug in Hornbill is preventing it from progressing correctly. This was not caught initially as we had extensively tested the processes with our Hornbill User accounts and it was completely fine, but when we tested it with a Basic User test account it didn't work properly. After several hours of debugging, we narrowed it down to the Hornbill Automation node Requests > Suspend > Await Expiry. We had set different Expire Periods of 1 hour, 5 minutes and 1 minute (we're aware the latter doesn't always play ball but seemed OK once we 'nudged' it) but it never expires and moves on. We are obviously testing this in working hours and with respect to the Working Time Calendar. The conditions required for this bug to manifest itself are as follows: It only occurs if a Basic User is raising the call, regardless of whether the customer is automatically changed to another user with a User licence later on A human never interacts with the call after it is created, AND before the first Await Expiry node is reached. This doesn't include opening and viewing the call Upon reaching the instance an action is taken on the call, such as posting to the timeline (analyst or customer) or assigning it to an owner, it kicks the Await Expiry node into gear and after the stipulated time it continues as normal. The types of request it is failing with includes service requests and change requests. It really doesn't make sense why this node only works as intended for Hornbill Users, so I would really appreciate if someone can confirm if this is indeed a bug or if there's some whacky reason behind it.

Apologies for the delay in responding, took some annual leave. Yes to both. I tried to select the team from the drop-down and set it manually via a custom field, neither of which worked. That is something I was aware of and suspected it might want the display name instead of a raw value, another example of which being the catalogue item field under Requests > Log Request, which I keep forgetting won't accept the catalogue item Id number. But inputting the display name of the team was also not the solution. I think I trapped myself into a hole here where I believed the ID of the team was urn:sys:group:TeamName, and that the start of this string (urn:sys:group:) was required based on other threads I've come across on this forum. However, after reading your reply it occurred to me that I don't think I tried just the ID ('2ndLineSupport' in your example) in a custom field, or if I did it certainly didn't work previously. I just gave it a go and it worked first time! Really unsure why this didn't occur to me sooner but at least I know which parameter to use going forwards. Thanks for your input all!

The service I was testing in was set to support all teams. However, off the back of your comment I created a new service, added a supporting team to test with, repeated the above using the new service and had the same outcome. Therefore something else is at play here.

I'm developing a workflow that needs to take some teams picked in the intelligent capture and create some calls within the same workflow, one call for each team selected. On the Log Request node, I have tried every possible combination to get a call assigned to a chosen team, but in every instance it remains unassigned when the call is raised and the workflow errors out down the line as it is looking for the currently assigned team for other stuff. In the Team field, I've tried: Using the display and raw values of the intelligent capture answer Populating a custom field with urn:sys:group: and the raw value, then feeding that into the log request node (e.g. urn:sys:group:TeamName Populating a custom field with the raw value of the intelligent capture answer, then feeding that into the log request node Assigning to the chosen team manually, then using the 'Get Team Details' node to try and obtain the TeamIdForTasks variable and feeding that into the log request node If I'm not mistaken, the format it is looking for is urn:sys:group:TeamName, and it just so happens the team I am testing is in the upper-most level so no forward slashes needed. Plus the service it is creating a call under is currently set to support all teams. I can assign the call through a separate assignment node using the display value of the intelligent capture answer, but this will lead to an overly complicated workflow as I would have to set up a lot of logic to filter each team and each call, and then assign. Please can someone put me out of my misery and suggest what value is required to get this node to assign to the correct team? Thanks

That might be it! The height seems to stay the same but the width of the images changes, despite the fact I specified said width. Our layout is configured to be 1140 pixels wide which is somewhat narrow on a 16:9 monitor so perhaps that might be a factor into whether the issue occurs. Thank you for investigating and I will look forward to the next update!

Hi @Daniel Dekel, This issue does not occur with any combination of the position of a second widget. I tried above, left, right and below the Links widget and the issue did not present itself until I deleted it, leaving behind just the Links widget (with 8 images as shown above).

Whilst designing a new page, I believe I have found a potential bug within the Employee Portal. An example of what I am trying to achieve is shown below: I'm adding one Links widget and several images with different content on, linking to their respective intelligent capture: (Obviously this is just a mock-up to show the problem ) You'll note that I also added a Search widget below Links, but if I remove that Search widget the formatting of the images change and they become squished: This isn't specific to removing the Search widget; adding any widget corrects this issue. The images start getting squished with the addition of image 5. I've had a good play around with all the settings in the Links widget (align to centre, use full width, use content height etc.) and each image has a specified width and height of 190x81 pixels, but alas this problem persists so long as this widget is the only one on the page. We have no other widgets to add to these sub-pages and do not believe this to be normal behaviour. Would it therefore be possible to confirm if this is normal behaviour, and if not have it fixed in a future update?

I brought this up a few months ago but didn't get a reply. It's interesting refreshing the page fixes it for you – myself and a few other members in our organisation have this persist permanently across different browsers and sessions, meaning it's tied to our accounts in some way as opposed to the mailbox itself.

Looks like it's working for me now, thanks again!

Thank you both for your speedy responses and for looking straight into it!

I'm working on a time-sensitive Workflow but am unable to do anything realistically as myself and others are getting the following errors across all Workflows: "Failed to load bpm flowcode script. Please contact support." "Failed to load bpm answers flowcode script. Please contact support." This seems to only happen for Hornbill Automations as soon as I click into the node. For example, this is all I see for a node updating custom fields: There is nothing below this so the entire list of custom fields is not present. The same can be observed for any other Hornbill Automation. Please can this be looked into as it's preventing any work on Workflows being undertaken. It was fine at around 15:30 (GMT) yesterday and only started this morning.

Ignore most of this post, I didn't realise semi-colon was the button to trigger email separation. Would still appreciate the ability to send previous replies in an email chain through the reply function instead of in just forwarding though.

Now that the new email function has been deployed to the new UI, it is no longer possible to reply or reply all to an email and quote the previous email chain. To do this, I have to click forward instead and then 'See forwarded content', then re-type the email addresses I want to reply to. However, it looks as though we can no longer use either reply or forward to send emails to recipients outside of the domain connected to Hornbill, thereby making this email system highly unusable in many calls. Could we have the ability to email external email addresses in the email function, and quote previous correspondence when replying to emails?