Berto2002

@Steve Giller are you able to point me to the area of documentation where I might find details of the visibility, please? I was hoping to see something but I am not sure what I am looking for. A search for "visibility" brings up a bunch of platform technical responses like this: Method - activity::activityPostCommentImage (hornbill.com) which has a "visibility" row entry stating "default=undefined Method - activity::postMessage (hornbill.com) which has a row entry stating "default=following" I am trying to find where it will be listed how these app settings affect things: guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.schedule guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.linkDocument guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.link guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.hold guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.authorisers guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.assign guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.assets guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.escalate guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update I am also trying to find out what the defaults are for each type of node if they are left as "Ignore".

I uploaded a 1.6Mb file as profile picture. No warnings or anything but it resulted in removing my profile pic so just had a grey blob. Tried again with smaller file of 350Kb and it worked ok So assume there's a limit and this should be published on the screen to avoid issues:

From a fellow user perspective it's upsetting our customers and messing with our workflow so I have asked Hornbill Customer Escalations to prioritise it. Hornbill noted on Tuesday 24th, "Our developers are aware that the fix in the recent Service Manager release does not appear to have been effective. They are looking into a solution and once I know more I will of course pass on the next steps".

Thanks for the response.

We often hear from our line managers or other connections (Basic Users) that they want to be kept updated on a Request. Is there any way they can be notified either through options or if anyone has found a way of capturing Customer or Analyst updates have having them pinged-out?

+1 for this. I would like to see us able to add Organisation Groups as Connections which would result in all the members of that Org Group being able to act as Connections. Use cases: Secretarial Pool supporting multiple execs and all need to be connections in case asked by any of them to look into their IT tickets Councillor Support Team is a virtual team of people we have as an Org Group (sync'd from O365 groups) doing as above for Councillors

@will.good you could do something with your Workflows. Imagine you have Custom fields A and B added to your Details Form for Service X, you can set them to be only visible when populated You disable the Edit of the Details section for relevant Workflows and, instead, the Workflow adds a Human Task for your analysts to update the relevant information Your BPM can detect which catalog item the Request was created through and divert the text entered in the Human Task to the correct field in the Details section (A or B ) The appropriate field shows in the details section as it's now populated Your Human Task can be on a loop and always re-present itself after it's been used so further updates can be made (overwrite or append in each case) until a second outcome button of "no more updates" is used Because Workflow has the ability to lock or unlock the Details section you could set-up two Custom Buttons that run Autotasks to Lock / Unlock the Details section. Trusted users who know to select the correct fields for that type could be given that ability to edit directly and would not see the Human Task version above (Workflow could find them as the Owner and not present the Human Tasks). Just ideas in case useful. I would NOT want the forms to be customisable per cat item; it's bad enough with 100 services having to manually reconfigure them one by one for 100 services let alone 500 cat items!

We are interested in SLA/OLA in relation to Suppliers so we can better access support and set expectations with customers and analysts. At a high level we would like to be able to: 'Assign' a Request to a Supplier Contract. Perhaps this is a new collapsible section in the Request where the Contract is linked (via a lookup of the Supplier) The Contract records would have fields for agreed operational performance (which may have to be freeform due to the infinite variations possible) containing relevant information such as: Supported Hours/Days/Times Response/Resolution times Contact / call logging details Pre-requisite information the supplier needs us to give The people involved such as our contract owner and their contract owner Escalation information Have the above properties of that Contract exposed in the UI at the point of linking/assignment with the usual visibility options for team/customer, etc. The aim would be that it's clear how to get support and what to tell the customer about how it progresses A tie-in in the sub-status that allows us to state whether the Request is or is not currently dependent on the Supplier (Contract). E.g. Request would be "In Progress (Supplier)" or "In Progress (Internal)" A future development of this would be to codify some of those fields (the most obvious being the supported hours and priorities) so some measurements of supplier/contract performance could be gleaned.

Connections. They are Basic Users. The use case is to allow a select pool of (secretarial) people to access Requests that are raised by senior members of staff; so when the exec says, "please sort that out for me" they can read and interact with the request.

All the new custom fields are there. There is no custom field 6 tho... the sixth field is and always has been Custom field F (A - T are 1-20) which is why the numbered ones start at 21.

@Met I stripped the report back and started again and I can now get a result with this: And it shows the obj ref urn data. I then applied filters and got my list of requests without tasks. Thanks for your help. I will now try to build back in the other data columns I wanted. Rob

@Met very kind of you to suggest this but my logic circuits don't compute what you've suggested... Your first sentence seems to say "return all Requests linked to Tasks" but the second sentence (the filter) seems to say, "and filter out all the Requests linked to Tasks" (which will be 100% of rows found in the first part). I have 4 tables but the link to the h_buz_activities and h_sys_accounts is just to link additional columns of data so I think what I have is Requests linked to Tasks with the Left Join you suggested. Buz to Requests: Requests to Accounts: Requests to Tasks: And has some basic filters including the one I think you suggested. The report runs for quite a time but returns no rows. If you can help further it would be much appreciated. Rob

I accept that's an idea that is similar but the important parts are: It's visible before opening the task It expires 'automatically' so we don't have to plan to go back to every node and take off the formatting

Summary: I would like my analysts (Full Users) to be able to quickly identify newly added or edited Human Task nodes so they are drawn to pay attention to them. We operate quite heavily on the principle of continual service improvement and iterative development of our workflows. We very often tweak the language in human task or add or remove step. We inform the analysts in comms or short update videos but in the heat of the moment when the analysts are running through workflows there is nothing to remind them when they hit one of those small areas that we've recently changed and sometimes that creates delay or confusion or errors. They are often running on auto-pilot and need a little hint to think at certain places. I'd very much like the ability to flag a human task node as having been recently edited so that it appears as a different colour to the analyst when they reach that stage of the workflow. How I see this working: As the designer of the workflow, I would simply like a box on the human task that I can tick to flag this as a new or altered human task node All the user interface needs to do is display that Human Task (activity) in a slightly highlighted colour. This will have the effect of alerting the analyst to pay particular attention when they reach one of these nodes to remind themselves of the change I envisage that any such flag would always be temporary and will automatically disable after either a defined period or the admin has a date selector (like expiry). That way the UI only highlights if the fixed date is in the future. I see this is a very easy thing to implement because it is non-functional; just a flag and the UI. Thinking ahead, it raises other possibilities such as the ability to colour-code tasks according to their function or importance. E.g. Asset handling tasks could be green highlight, account management red, etc; enabling analysts to see at a glance the type of work to be done. I imagine this sort of thing: And it would look like this when opening the task: Here are two options as to how it might look to the workflow designer. 1) a simple tick box which activates a 4 week timer each time the node is edited and 2) setting a specific day/month/year for the highlighting to expire (my favoured option) I would welcome any comment or support for this analyst/usability/change focused suggestion.

Hornbill did get back to me yesterday but implied it was due to a string util giving a blank value but I explained that was not the case and gave the evidence so now hoping for a new response.

I would like a list of Active Requests where the required work by analysts is not driven by Tasks. That means knowing all Requests where all tasks have been completed or no tasks ever have been added. In my mind I believe this means I need a report which includes data from Tasks because you can't tell from the Request table if a Request has tasks or what status they are. But I don't think this works: If I link Requests to Tasks (e.g. as per below that we have in another report), then the report will naturally always exclude all Requests that have no Tasks at all If I don't link Requests to Tasks, I cannot at all determine if a Request has or had a task and what its status is I am trying to think through how I can get a complete list of Active Requests (period) and the task Title and Details only appears for those that do have tasks (with multirows if more than one task); where there are no tasks or only completed tasks, we see no task data. So I cannot see a way to get my desired outcome: Requests where all tasks have been completed or no tasks ever have been added. Any ideas please?

I have chased this with Customer Success. You still getting this @AKJ?

+1 for this but I acknowledge this would come down to having a firm requirement. For us it's something like: A permission that allow FAQ, Bulletins and service status which we can give to service desk and triage teams Allow the defined Service Owner to edit all other fields (SLA, Assets, Docs, etc) except Config (read only) Require an admin-level permission (Service Manager-level configuration) before being able to alter anything in the Config section (cat items etc) This is because: triage and service desk need to keep our customers updated on services the service owner is responsible for aspects of their service but they are not responsible for forms and workflows and could mess things up badly by altering things in config only trained ICF/BPM admins should be able to mess with Config to keep the risk down

@Osman you can use an inbound email rule to pick-up these emails and send an email to the customer via a routing rule template in Service Manager. Below is ours. We use the inbound rule to catch all emails not otherwise attended to because we have a zero inbox policy for service desk and do not attend to any emails manually. The email is therefore a catch-all for any of our customers' domains which explains a number of scenarios where the user may receive an auto-reply and gives them reasons and a way forward:

Flagging to front of queue in case anyone else agrees 'pinning' the header bar, hub and info box would be useful in light of the new UI changes.

@Daniel Dekel is this issue for this UI list or want it logged as separate forum post? When the Full User has a long title, it does not wrap and pushes the buttons out the right of the box:

@Miro in the 2.5 years I've worked on this tool, there has never been a "how this field in summary..." field in the override flags area (although always wondered why that is the only one of the 5 options missing!)

Hi @Miro, Many of these Form Fields have over-ride conditions. This is the list of italics/non-italics that shows the full list: However, the override conditions do not have the "show this field in summary..." option: They rely on the option being set in the Default flags and we have all those set to ticked: Two fields that have NO overrides are the start and end date as below and these are not showing as we fill them in: Configured thus (no override):

I was logging a test Request through the front-end today and the answers to the questions are not appearing in the Summary Panel as I go. All the Form Fields have "Show this field in summary panel once form is completed" ticked (checked). They all suddenly appeared when I ticked the last box on the form: Which is configured like this. I think there's something in the background that is only showing the answers in the Summary Panel when the Next button is eligible to be pressed on the form? Or perhaps it's when certain mandated fields have been completed? I did a new test and ticked the last question FIRST (the one at the bottom) and then, all the rest of the fields did appeared as I filled them in, as expected. I think we have a defect here.

We have a Premier Support ticket outstanding for this defect because it's pretty serious (many people logging tickets on behalf of someone else are getting them logged in their name so we can get software installed for the wrong people!) and HB are looking at this with development. I believe it was thought resolved in the September release but it was not.