Berto2002

I have found a 5th different help text for node "SM>Entity>Requests>Authorisation Decision>Approved" which states: "This option determines the visibility of the post to the Request. When not supplied, the setting "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update" is used to determine the visibility." This is in line with A1 above.

There is a lack of clarity / documentation about how Visibility works. Could I please ask HB to update Wiki or this forum to make it clearer? A. The pop-up Visibility help seems to have FOUR contradictory entries (that I have found), each giving different advice: default is customer or team or application option or not defined! SM>Entity>Requests>Update Request>Request Category. Visibility help: "The request timeline post visibility. If not specified, the application option value will be used" [BTW, great, this is what I expect]. This approach is supported by various "Visibility" entries on this Wiki age: Service Manager Business Process Workflow - Hornbill. SM>Entity>Requests>Update Request>Service: " This parameter determines the visibility of the post to the Request." (no mention of default) SM>Entity>Requests>Update Request>Custom Fields. Visibility help: "This option determines the visibility that will be applied to the update in the Request's Timeline. If not specified, 'Team' visibility will be used" (in direct contradiction to 1 above) SM>Entity>Requests>Update Request>Timeline: Visibility help: "The timeline visibility that will be applied to the request update post. If no value is specified, the visibility will be set to customer (trustedGuest)" (in direct contradiction to 1 above). I believe I have found examples of this where I set the app setting to "Public" but the node to "Ignore" and the default for Update Timeline was "Customer" (see F below) The above gives great concern that Visibility is either inaccurately documented or, worse, actually coded to have different behaviours per node which is an admins nightmare. B. Some nodes have this field as "Visibility", others as "Timeline Visibility" but it's not clear what the difference is. C. I have seen that my customers do see "Public" posts so it is not clear the difference between Public and Customer. All my IT analysts can already see posts set to Customer so what is the benefit of "Public"? I think this is partially answered here by Victor but it would be good it have it confirmed: D. It is also not clear what the setting should be for when I want "all my Full Users to see it and no-one else". Is that "team" (as in all Full Users, Co-workers) or "team" as in assignment teams (service desk, infrastructure, etc). If so, does that mean there is no setting where I can say "all my Full Users to see it" and no-one else"? Here in relation to (Buzz - Hornbill) it mentions "Public" as "All Co-workers) but not sure if that's related to Requests (but does set a precedent for what "Public" is). E. It is not clear, when the guidance says, "If not specified..." whether that applies to both "ignore" and "auto" settings. F. I have a support ticket open specifically about when I set default in the app settings for Request Updates to be "Public", they default to "Customer" in the UI. but that many be because the node is configured to not use the app setting but default to Customer as per A4 above. G. Doing a search on "Visibility" on Wiki produces no results so I've been struggling to understand this feature. I know there will be something there but I suspect it is behind a "Read More" filter which means it's not found on searches unless expanded... If a Wiki article can be please created or updated with this information I think we'll all be better off. Please help get this all bottomed-out. For reference, the application settings/options I believe should be used in the absence of a spec (ignore or auto) are: 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

@Victor. I had a ticket with Support recently and I am sure @Deen advised that Public was all the Co-workers. Since all co-workers can automatically all updates with visibility of Customer, it makes no sense for Public to do exactly the same? Please clan you clarify whether customers see Public updates and if so why/how they are different from Customer updates. Thanks

I have a Human Task that is hardcoded to assign to a Role but I want to determine the assignment according to an earlier decision in the BPM such as: If the Request is for the infrastructure team I want the Human Task assigned to Team - infra Else I want it assigned to Role - app support as per below screenshot because apps have multiple teams but share a role Question: am I right thinking that the Variable option can only contain a UserID (i.e. a single person) and not a Role or Team or Group? Implied by BPM Human Tasks - Hornbill In which case I would read the options as: Assign to Role Assign to Group Assign to User Assign to User Variable i.e. there is no way to make the assignment by ROLE, TEAM or GROUP variable?

@Nanette has this been resolved in the background now? We had a couple of requests yesterday that did alter the customer. The defect never showed-up on the list in your portal so I cannot track it. Or is this only happening under certain circumstances?

@Gareth Cantrell (edited). Found it: Authorisation Action Item - Hornbill

I get it. Sorry yes I did see something about that. Looking forward to that one.

Hornbill ESP - 07-08-2023 09:16 (Build 3779) "Entity email templates can now be flagged available for interactive and/or automation use, allowing for a significant reduction in choices when browsing and selecting an email template" Where is this please? I can see the Grouping but not the flag you mention. Nothing here in Wiki: Email Templates - Hornbill?

This is currently under investigation by the developers. Initial hypothesis: if requests have been placed on hold more than once it might be using the times that have been set to come off-hold in the first on-hold action.

I made a quick report to see a list of all of our services and there were 272 rows which is about double what we have. On review, I find each Service shows-up twice but the second row in each case only has a sub-set of the data; it's a kind of 'ghost' record. Have we got duplicates? Do I log this with Support? Example: At the back of my mind I seem to remember a report we had done only included records with "Default Service Language" as "is set" and I wondered why. All the 'true' rows (i.e. ones with the most data) have this set. Is this why? Is this by design?

Our users told me they received a "Try again" error about 8.45? a few minutes later they got in?

@samwoo, @Adrian Simpkins do you guys have this set? Any experiences here?

+1 I have previously requested the ability to filter-out retired assets because my users and analysts can never tell which assets are retired so keep adding them to incidents and changes which really messes up our asset control...

Yes, we are getting this too sometimes. We have logged Premier Support ticket for this. Did you also see "Max exec loop count set to 1000" repeatedly showing in the logs? We found it was coming off hold about 30-60 mins after going on hold and I suspect an internal loop in the system which takes about that amount of time to do 1000 iterations and then unholds the ticket. This is one of several issues I think HB are dealing with relating to on-hold and timers. We've also reported tickets not coming off hold when they reach their time which appears to be related to the start/mark response and resolution timers.

Nodes in the BPM that update the timeline (and which for an odd reason are listed against the Customer's name) also are going out as Customer visible when visibility is configured in the node to "Ignore" (i.e. should be using the app setting):

I set "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update" to Public and yet all the Requests then have the default of "Customer"... but I did not select Customer, I selected Public (and Public is open to all my analysts but not the Customer, I believe). This setting: Gives this result: And this setting: Gives this result: Indeed, while there are five options in the "guest.ui.app.com.hornbill.servicemanager.operation.defaultVisibility.update" settings, there are only two for Updates in the UI: But I would have expected to see all five options there on the UI? Perhaps this explains why the Public Setting is not working; it is trying to set Public but then defaults to Customer as not a valid option? But then I notice this dichotomy exists for the equivalent Assets setting too; but the Public setting does 'take' even though there are only two options in the UI drop-down:

On 18/07/23 Hornbill released Service Manager with this enhancement which was great: Support for "Search co-workers by group" in custom IC forms {CH00177049} Just starting to test it and there's a mis-alignment of field names. In the organisation config, the field is called "Organisation Id" but in the IC forms, it askes for "Group iD". This doesn't seem in keeping with HB's normal precision when naming fields. Request alignment of these terms (i.e. use "Organisation id" in the IC form).

Yes I guess that does show enable it. But this is one of those areas where a global setting would be much more useful; perhaps as an over-ride ("Always show form fields in view mode even when no value"). It's also a mixed use field which I believe mainly comes into its own in the view mode in the Requests themselves. However, in the context of a Service Portfolio configuration which is specifically for viewing and editing the design - and thus where there fields will always be empty - I suggest it makes little sense to use the request-focused view setting here. It should show all fields and identify the read-only ones with a 'flag' of some kind. I have 50 services that use a custom change form so ticking that box on all 15 fields for 50 services is a whole day of effort and some RSI issues. I certainly accept this is not a defect but I do suggest it's not a very usable design.

When I open the form designer, it just shows Summary, Description, Site but my form has a whole heap of other fields in it. I have to click the "design" button before I see I need to make edits. it would be useful for me for the "read only" version of this form to show me my existing configuration so I can see design at a glance. vs In addition, I request the Apply Changes button be placed at the BOTTOM, next to the Close button and for them to named better: Save and Close Save and Discard Changes The number of times I have edited and clicked blinkin' Close and lost my work because the "Apply Changes" button is at the top and has scrolled off the top!

@Dan Stewart did you get what you needed? I would be happy to share our set-up in a call so you can get another viewpoint.

I guess it is related to this feature where the sending address can be set. Assuming this is new and enables us to go back to the original.

We've had some inbound routing rules not work this week. When I compared the rules that failed/succeeded, the obvious thing is that the sender address was "Hornbill" (xxx-mail@live.hornbill.com) and is now "Do No Reply-xxx" (donotreply-xxx@live.hornbill.com) Please note the typo in the name: should be "Do Not Reply"? So will this change again? Would have been good to have this change notified TBH (or was it on release notes and I missed it?!). Have any other sender/recipient mailbox identifiers changed?

In my mind AUTO is obvious, though. Just as AUTO on the Request ID picks up the current Request ID, AUTO on a User ID field that is named "Add Customer Assets" should pick-up the Customer's User ID; and at the very least it should pick-up nothing (not a connection with the line manager) ... but as I said to Nanette on a support resolution, if it works, making things work the way I want them to is not your job and there are more important things of you to be doing

I noticed we have this issue today. The system does not seem to be able to wrap the URL correctly and extends the box in a crazy way. It feels to be that the issue is with the Outcome field because there was only an issue once I selected Complete and got the Document Link box. The config of the node is just this: Although I know we can shorten the text for URLs I prefer showing them in full as good practice where we can so people can trust the target The functionality is NOT affected by the above issue.