Berto2002

I have the "Network and Infrastructure Support" Service Portfolio item with Change Config on, Subscribers as an OG Type Company and no restriction on the Cat Item visibility; and none of our Basic Users have ever been able to see or raise CRs because we have this setting off: guest.servicemanager.portal.additionalRequestTypes.change. Allow Change Requests to be raised through the portals using Catalogs and allow all existing Change Requests with a customer associated with them to be visibile [sic] in the portals. I created a new Service called "Liquidlogic Childrens System (LCS)" with Change Config on, Subscribers as an OG Type General and no restriction on the Cat Item visibility; and the Basic Users CAN see and have started raising Change Requests. Infra and Network: User in one of those Companies sees this on portal (no Change item): LiquidLogic Service config: User in the LCS Users Subscriber list sees this on portal (DOES SEE Change item): It seems to me that the new Service is not observing SM Application Setting (guest.servicemanager.portal.additionalRequestTypes.change) which should be preventing Changes from being seen on the portals. All our other services are and have been since launch 3 years ago. I tried adding the Subscriber OG Type General to the Network Cat Item but that did not trigger the same issue. I have worked-around this by altering the visibility settings on the catalog item but we need to understand this going forwards.

Two ways for you, using Connections On ticket logging: In the Config for the Service/s concerned, set the Connections options to Allowed for both View and Collaborate for your desired connection type (e.g. Connection Type "Interested") Configure your ICF form to give the user options to add other people as collaborators for their tickets each time they log them; these are user pickers; give them as many fields as they want and you could even give them a choice of adding people who can view or people who can act on the ticket Set your workflows to detect if each of these fields is populated and if so to add that person as a Connection of the relevant type to allow view or act They will then be able to see that ticket through it's lifecycle using the "Connections" tab/view in their portal At any time in the lifecycle (we have this for some teams): Code a very simple workflow that allows an end user to enter a Request (ticket) number and a person from a user picker The Workflow receives that reference and uses it to add the person as a Connection to the ticket reference Privacy concerns: Use the Subscribers feature to lock-down who can access this form so it doesn't allow anyone to access anyone else ticket. For example, either maintain a manual Organisation Group with this team or sync-in from AD to that group You can have a check in the workflow that adds the Connection to ensure the ticket being updated meets certain criteria so they cannot add themselves to unsuitable tickets. E.g. We have a team of PA/EA/Secretaries who support Councillors and they have access through a Subscriber-restricted Service to run this 'add collaborators' workflow to add themselves to any Councillor ticket using a check that the Customer of the ticket is in the Elected Members Organisation Group which is maintained and sync'd from Active Directory.

I this the wider request is for HB to make the engine behind ICF align with BPM (Workflow). It's clear they came from different places and there are various misalignments. However, I see these as very minor. Other things are like: It's called branches not decisions You can't right click and insert a node, you have to disconnect and then string-out No parallel processing

Although we don't have this issue on cards that are added, updated and moved by the workflow:

Perfect. Obvious when I think about it... Thanks! asset-history-for-selected-user-variable-to-enter.report.txt

Messy buttons when generating support passcode. Looks like it's caused by the width reduction/margins/spacing issues and causing wrap

Maybe I mentioned the wrong thing... It looks like this: { "APIKey": "xxx", "InstanceID": "xxx", "Schedule": [{ "Enabled": true, "CronSchedule": "0 30 8 * * 1", "DayOfMonthANDDayOfWeek":false, "ScheduleFrom": "2023-06-06T00:00:00.000Z", "ScheduleTo": "2030-06-09T00:00:00.000Z", "Service": "apps/com.hornbill.servicemanager/ServiceRequests", "API": "logServiceRequest", "APIParams":{ "0": { "Type":"Content", "Parameter":"summary", "Content":"Patching Updates - Test - 2nd Weds of the month" }, "1": { "Type":"Content", "Parameter":"description", "Content":"xxx." }, "2": { "Type":"Content", "Parameter":"requestType", "Content":"Change Request" }, "3": { "Type":"Content", "Parameter":"customerId", "Content":"ServiceDesk@xxx.gov.uk" }, "4": { "Type":"Content", "Parameter":"customerType", "Content":"0"

We're successfully using the API scheduler to log Requests. Now to do Change Requests... Using this: Operation - com.hornbill.servicemanager::ChangeRequests/logChangeRequest I created my JSON file but then I realised that change scheduling is a different page: Operation - com.hornbill.servicemanager::ChangeRequests/schedule Question: can I append the fields from the ChangeRequests/Schedule to the initial list of parameters in the JSON file so the Change gets scheduled when first logged? Or do I have to complete once operation, receive the RequestiD and then have another operation to update the CR with the Schedule details?

Thanks. Then I will wait and likely still want to use that General OU type for my purposes.

Yes I get the same issue when using a link (https://docs.hornbill.com/esp-fundamentals/core-capabilities/organization-and-teams

@Steve Giller is there is list of restrictions by Org Type in the documentation for allowed uses? Why design this restriction; why not let us customers decide what users and roles and organisations we use groups for. I have loads of functions all over the wider organisation and I cannot use the Function Org Group for them.

The selection I make in the Workflow filter is no longer retained by the system and defaults back to "All workflows" each time the tab/browser is closed. For the last 2.5 years I have had that set at "Show Active Workflows" (Show Active BPM) which is what I need 99% of the time. Please can we have this drop-down reverted to store/save the preference? It's the same in the old/new UI so this is not a UI issue but maybe altered with the SM release when the name was changed from BPM to Workflow?

I created an Org Group of type Function and the only members I can add are Full Members. Is this intended? Use Case: I have a bunch of people in the wider organisation forming a function of approval of mobile phones so I wanted to use that OG Type for Basic Users.

Thanks both. I thought that was the case I guess.

@AlexOnTheHill 100% with you here. This UI update is a backwards step in terms of useability and agent productivity with overall reduction of useful information on screen at any time, additional unnecessary clicks and wasted screen real estate.

I can see settings for how to alter (what I call) the request reference prefix (IN, SR, etc) for the 5 specific request types. What I cannot see is whether it is possible to have other additional prefixes. For example, I would like some of our SR requests to be CS (for Case) at the start; but they would otherwise be normal SR's in all but name. Is this possible? I'm struggling with finding anything in the documentation in this area - largely because I don't now if I am searching the correct term... 'prefix'? Thanks for any advice.

@Dan Munns you should log here: I suspect HB should shut this thread as duplicate for above.

Yes there's a few of these (see above for my post on the global search bar now being a magnifying glass icon you need to click to expand before entering the data). I'm overall impressed with the visuals but I think HB have not prioritised user productivity and usability; the amount of useable data on the screen throughout these updates has reduced and the number of clicks and scrolls is increasing. I really wanted to see more relevant information for analysts presented on page 1 of any required update, reducing clicks and scrolling. When opening a Request, the analyst needs to assess "what is the required outcome and what do I need to do next"; all that information should be cleverly displayed once the page loads and they should not need to hunt for it.

Sorry but I really do not like the new email UI. 1) Our email header graphics are missing when viewing the emails in the new Email UI: Old UI: New UI: 2) In the above, the To is not showing. We have to click on the twistie to see who it went to which is no good: 3) you've spaced it all out too much again so the list of emails in any mailbox is now only showing a few so we have yet more scrolling and clicking to get the data! You've reduced the amount of usable data on the screen; reducing productivity of all HB users. I used to be able to see 12 emails in the list (including preview) before scrolling but I can now only see 6 (with the preview open which is essential to read what the email is about): a 50% reduction in the amount of usable data on the screen . And the list of emails is 50% narrower and cannot be resized.

There is a search function of course; just start typing. but it doesn't help people who don't know what they are looking for. There will also be (soon) the ability to limit which templates show here so all the back-end ones can be hidden from analysts). but that doesn't excuse all the unnecessary extra line gaps in a basic list

Not a fan of all this unnecessary spacing in the new email view and drop-down for email templates, Just more scrolling for everyone. I am not sure HB have really thought about the amount of scrolling necessary over-all to manage tickets. The mission should be more usable information per page not less?

The Request main view has been made yet narrower when it was already too narrow in my opinion. Was width reduction in the requirements or requested by customers? If not, why has it been done? a) Using a measure on my screen at set zoom, the Details section is 17.4cm wide in old UI and 16.4cm wide in new which is a 6% reduction in width b) The Details box has bigger margins to which, on the same relative scale means the Old UI text width in Details was 16.4cm but it's now only 15cm which is a 9% reduction in width Old UI: New UI where the words "Housing Benefit" have scrolled to the new line" because a) the Request width has been reduced b) the margins inside the collapsible sections have been made wider As a result, most tickets now required excessive scrolling. I request all the widths go back to at least where they were or preferably larger or intelligent width depending on browser (like most other systems in use these days).

I don't like the fact that the new UI has a collapsible search area. We use the search ALL THE TIME but this change has just given us all an additional click every time we want to search for something. This is a productivity loss for all HB customers. There is no gain to hiding the search because there is nothing else on that layer of the UI to clear space for. I request reverting this to permanently displayed search bar: old: new

+ 1 we have this problem; big issue for customer relations; we must be able to hide if mistakes made.

+1 Action bar icons must be one line. Relates to the fact the Request display panel is too narrow.