Berto2002

@Gareth Cantrell that is very useful to know and it makes sense as a design. So the only storage issue we may therefore have is the 245 versions of our generic workflow

I have been running a test for a change release today but spotted the absence of the Low/Medium/High that normally appears as you progress through the Impact Assessment. Last time this happened, it was found that the Impact Assessment was not setting the Impact so we put-in a workaround to default to Medium if none was found. But I think this could cause issues for some.

@will.good, @Adrian Simpkins, @HGrigsby, @Gareth Cantrell @EWA would be interested in your thoughts about this. @James Ainsworth When I download my two most common workflows (generic incident and generic request), they are 1.5Mb approx in txt file. Visually, see screenshot for how one of these standard workflows looks for reference of what 1.5Mb is (plus one smaller stage for closure). We get through 200 of these a week so are we really talking about 300Mb? Other customers much more of course. I guess database compression etc makes storage much lower but how much lower? James, can you please ask Devs is that is the size of a retained BPM against each Request vs it's text file size (or other stats like the percentage of storage taken by a workflow vs the request data itself)? If this is a significant number (and I think it must be if the full integrity of the workflow is maintained for every historical Request), there will be a clear case to enable discarding the workflow/BPM according to a system setting and would likely have it set for 1 year +. Historical tickets for us are really only ever about the Request data and are never looked at in order to see HUD information. I would venture that the space saving opportunity here is so significant for HB customers and HB that it may even be worth coding a 'snapshot' view of the HUD which is set as part of the BPM/workflow removal process; so the HUD remains but as a static view. I remember at HUG someone mentioned you were considering more about the data retention now the system is maturing; and this could be a great enhancement to put on the list.

And how about the idea that much data could be saved if the BPM itself was removed from the Request after a certain time, like the Log is?

In addition to the lock-unlock node suspend causing errors and the suspend for Assets causing errors, we are now also seeing it in suspend pending customer feedback. Request Hornbill please address these suspend issues with rapid patch, it's making all the admins run around to restart broken workflows

We've started seeing this now also. Hoping for a patch on this or faster-than-usual release. This is similar to the issue with the Suspend for Asset. These two issues are starting to create the perception in the user base that the product is getting unstable.

I recall in ESM there were to be configurable request types so customers can be more flexible

Old documentation on storage: Managing Instance Storage Usage - Hornbill which I hope will be migrated over at some point to new KB. I think there is an opportunity for an enhancement here @James Ainsworth. At present only the logs seem to be deleted after 7 days but we could set a retention also for the workflow (aka BPM) to be deleted from Completed Requests. Hornbill and customers could save a huge amount of storage (costs) since the BPM config files can be Mb each?

Confirming it works again and we use it in Autotask to dump the presence to the timeline in w single click:

I stand corrected. I thought the BPM/workflow also was removed but it seems it's not. I have also gone way back and can see each BPM/workflow attached to old tickets. There appears to be no process for the BPM to be removed.

The Workflow instance that is created for a Request is removed, I think along with its log, 7 days after the Request reaches the end, assuming it's not in error. There are quite a few posts around from HB staff confirming this. The way to ensure they don't stay around longer is to have a housekeeping regime to check all workflows reach their full and proper end node. Any left in a perpetual state of suspended, hold, or in failed state will stay around forever and use-up storage. For example, one of our reports looks for those in closed statue with BPM status of 4 (suspended). If a request is closed and the BPM is not ended then we have a workflow issue so we analyse the requests and then fix the issue allowing a close before it ends and then cancel/manually address the offending tickets.

ooh no, should be required +1

We used to be able to select a connector or node in ICF edits and press delete to remove it. That is no longer working and we need to right click and select Delete from the menu. Please can this be re-instated? PS it still works for Workflow to use the delete key.

Ah, actually, on the ICFs in basic user view, the mandated field is teal until clicked and then goes red.

You can see the little bar on the left should be red for mandated fields but it's started showing as grey in the UI. Does not even go red when highlighting or when populated:

And, as per my previous request of this type, the ability to have all updates to Customers go through teams also; at the moment, the only notification option for updates of visibility Customer is via email.

Have asked for Premier Support on this one.

I was trying to search emails this morning. My default sort order on the folder concerned, pre-search, is newest first: I enter "Approved" as a search term because I wanted to see all the emails **recently** that have that string: The sort order has reversed and I have no option to change it because the sort order options are absent. I have 316 results and 20 results per page so I need to scroll to the bottom and press next 16 times to get to the newest entries for that search; which is pretty bonkers. So I request that sort-order be please added to the results of the search (i.e. as it was before searching) and that the sort order of search results observe the sort order present at the point of the search. Additional information: the sort order is UNKNOWN on searches so anyone looking in date order will be unable to find things on searches.

@Fizza thought you were going to report this Yes, pretty sure this is a bug. We get no result for logonID from the Get Customer Details node. For some time (maybe years... since I learned this on implementaton) we have used primary email address. Can that be right we've just ignored such a thing?! My profile has logon ID (never really clocked the profile doesn't have CustomerID but uses UserID...): Config of node to push Get node outcomes to Timeline: Timeline output showing blank logon ID: Would also ask for comment from HB about these discrepancies: - Get node is missing an output of User ID and Employee ID, both of which are on the main user profile record - What is relationship between User ID and Logon ID officially? - Why are the user's profile details form (where they can add a secondary email address and other fields) and the admin User Profile view not aligned in terms of fields included?

+1 for convenience but we don't alter it often

The Azure Import Utility can sync-in users' line managers from AAD so they are then stored in your instance against the users' profile. The Get Customer Details node then gets Manager Name and Manager ID of the person who is the Request Customer. In our instance the Manager ID is the email address; else use that Manager ID to do a second Get Customer lookup to obtain the manager's email address (&[global["flowcoderefs"]["getCustomerInformation"]["primaryEmailAddress"]]). So thinking you don't need to go into AAD for this.

We have this too. Looking out for the fix

I tried another test with the authentication user and it still gave the same error:

Keeping this at the top

@Joshua Howitt The 'User ID' that we use to Authenticate the connection between Hornbill and Microsoft Office is our ServiceDeskID (the admin user in Hornbill). The UserID I used in my test (that worked on 6th March) was that of our infrastructure manager who has altered their Outlook permissions to allow the ServiceDeskID (the one we use as KeySafe/API/Admins) to Edit their calendar. I used this variable: &[global["flowcoderefs"]["getReqInformationEndStage"]["customerPrimaryEmail"]]. So the ID was neither mine (SessionID) not the ServiceDeskID. I then altered my requirement to add the calendar entry to the calendar of the Owner of the Change Request, not the Customer so I used this variable: &[global["flowcoderefs"]["getReqInformationEndStage"]["ownerId"]]. This is where I got the error, despite the actual ID that pulls back being the same person as I used above. Again, the ID was neither mine (SessionID) not the ServiceDeskID. Are you telling me that the UserID has to be the ServiceDeskID? But if so, that was not the case on 6th March so has this changed (there was a Service Manager release between the two tests I did)? It is also not in the guidance for that field which states "User ID that entry will be assigned to". We were able to use the UserID for my infrastructure manager on 6th March.