Berto2002

Confirmed. Found them and they were also all missing statuses so added back in and now the list is filtering correctly:

@David Hall er, and I think the Questionnaires are missing? We do have Impact Assessments configured and working in the Request UI but none are showing here for edit (regardless of the filter I select of Active, Draft, Offline.... Questionnaires (hornbill.com)

However I confirm I could go into the Assessments directly (not from the search) and while all the statuses show as active, when opening, they were not so I have re-set as Active and saved and will check next week if this restores the impact assessment outcomes. I accept your confirmation that this bug/nuance was inadvertently introduced in a release

@David Hall something is broken in teh search. I cannot get to the Assessments configuration. It's 404 from search I click here: And I get this:

@HGrigsby, yes looks like we've spotted the same thing. Impact Assessments are not working after the latest release; this has happened before. I reported it in the linked but we have a default Impact of Medium which kicks-in if the impact Assessment fails. Needs fixing ASAP

You could build your own 'repeating' workflow for this so the first Request the user logs would 'spawn' additional requests. ICF captures first device in field_1 and then it presents option to enter a second device (field_2) and so on up to the limit you would allow in one ticket Workflow is configured to spawn a build ticket for the details from field_1 and then decide if if field_2 is populated; and if so to spawn another ticket for action Repeat the above for the same number of these iterations in your workflow as you have options to enter multiple devices in the ICF The end result is one ICF spawns as many build requests as you want to provide for. Just tell the users the limit in one ticket. You could have this Workflow as stand-alone (so that Request always closes once it's spawned the required number of build tickets) or have it act as the 'parent', collecting and feeding-back the build outcomes from the 'silent child' tickets it spawned

@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: