Steve Giller

I've flagged this internally with our developers.

@Lee C Please try to avoid tagging people unless they are already directly involved in a discussion, as this gives the impression that someone is already leading the conversation and, especially in cases like this where the person you've tagged is not the most suitable for the topic, can prevent you getting the answers you need as it may discourage other users from responding. I've also moved this topic to the correct "Reporting" forum.

It's not clear where in the product you're hoping to see this, but based on the most commonly used areas, the Views are dynamically sized, and manual resizing is not something that there are any plans to implement (I'm not even sure if that's possible.) The other two requests are features that are more suited to, and definitely available with, our reporting functionality.

That's not really something that can easily be addressed on the forums, as it would, with apologies for the predictable comment, simply rely on what you need them to do. They would, as you've found, need to support each Service that they interact with. They would also need Incident and Service Request Management roles (again, the level depending on what they need to do) and potentially Board Manager, email etc. for triggering related actions.

Hi @JJack If you're on version 4.x this should auto-update (until v.5.x is released, anyway!) If you're on version 3.x this is deprecated, may well stop working at any time, and we would strongly recommend updating as soon as possible.

That doesn't look like correct response for the payload given. You should get something like: { "@status": true, "params": { "teamName": "TEAM", "ownerName": "OWNER" }, "flowCodeDebugState": { "executionId": "2508a577-fdab-44ee-871c-e8f8abde6b55" } } Have you established a valid session first?

This has been discussed previously, but no-one has been able to define what the "Next" or "Previous" Request is. A User can create any number of Views of the Request List and may have access to shared Views created by other Users. They may Own Requests, be Members or Connections on a Request, and Requests can be assigned to a Team they're a member of. A Request List View can display almost any column in the Requests table, be ordered by most of these, and a User may have multiple different Views open at any one time. Finally, these lists are dynamic, so the order of the View may have changed in the background while the current Request was being worked on.

Try putting a Get Request Details node immediately before the Task so that any changes in the Request state are up to date. Additionally, check that the Owner has "Assign Task" and "View Task" set in the relevant Team settings.

I'm not aware of any movement in this area to report.

Firstly, check you used "Owner (For Tasks)" as the variable - it appears that you did from the next image, but a second check never hurts. Assuming that you have the correct variable, this is almost certainly that the Request does not have an Owner at the point where the Task is created.

Currently the only available workaround is to restart the failed Workflow. We appreciate this is not ideal as it requires manual intervention and only a select few Users will have that capability, which is why we are investigating this as a priority. We will post back here when we have further information so that anyone without a Support Incident raised can see the progress.

Hi @Sana We're aware of this issue and this will be addressed in the next Service Manager release.

This issue will be resolved in the next release of Core UI. Keep an eye on the Announcements forum for details in the release notes.

Email does not support wiki markup, only plain text and HTML Basic wiki formatting can be applied to an email template variable with the |wiki modifier as detailed in the documentation.

Just to update this thread, we have, with @JAquino's help, managed to reproduce this issue and we expect a fix to be in the next-but-one build of Service Manager. Defect Reference: KE00181885

I haven't tried this, but using the windows key with "." should bring up the emoji picker, in Win11 at least. That might be how.

How are you populating the Manager? Is this from an import? You can edit the details (with the right Roles) on the Admin -> Platform Configuration -> Users page but if this is a scheduled Import this will be overwritten next time it runs.

The first thing to check is that the Azure userPrincipalName exactly matches a single User ID from your Instance.

If the screenshot is of an email that uses a Date field variable, then this will be because you have chosen not to format the date and are simply passing the database value, which is stored as UTC. Information on formatting dates in email templates is on the Documentation Site. Please note that "the email has changed it to an hour either side" is not correct - UTC does not change, it is the change between GMT/BST that causes this.

The Database Schema Viewer under the Entity Explorer within the Service Manager admin area will have all of the information for the fields in the table.

This depends on what the information is and what is already set up, but a decision node branching on the value of the question should be sufficient.

Hi @Euan Coleman Could you post a screenshot of GSA00144639? Something like this with the necessary redactions should be helpful:

Could you give some more details, as this is working as expected for me. Possibly a screenshot with any personal/sensitive information removed?

All of the information is on the Hornbill Documentation site. For our external tools the first step when you have an issue is to always to ensure that you are on the latest release, as this will have the most up to date feature set and bug fixes.

@billster Just for clarity, the screenshots you're sending appear to be within a Request workflow - this is only created when a Request is raised, so there would be no possible way to prevent one being raised at that point, although you could automatically (and silently) resolve and close it. The action you have taken with the Inbound Routing Rules is the correct one for this scenario.