Steve Giller

We have released a patch to resolve this issue. Please test again and let us know if there are ongoing issues - if this doesn't Just Work™ please ensure you've cleared your browser cache.

@grayat If you could review the wiki documentation this should have the information you require, if not please post back with further questions so we can answer those.

Our developers have identified an issue which they believe to be the underlying cause, and are investigating this. I'll update here as soon as I have further feedback. Please accept our apologies for the inconvenience to the Users who are experiencing this issue.

There isn't a "Get Asset Details" node available which would allow you to gather this information. I believe this is because you can add any number of Assets to a Request, so the Workflow would not know which asset to get the details for. I appreciate that in this scenario you would only add one Asset, but the Workflow isn't sentient (yet) so we cannot rely on the Request having a single linked Asset. I've tagged this as an Enhancement so that the Developers are aware and can asses the feasibility of this.

@Amanda Durgan We've responded via the Support Request.

@Dawn Bluck We have a support request raised for this, and will address the issue there.

@Martyn Houghton We've spotted this one and fixed it, although I don't have an ETA for the fix as yet.

Maybe you could enforce some draconian punishments for your CMDB admins in the meantime?

In-browser notifications might be a good idea here? I'd always argue that if the analyst is "not monitoring" x, why assume they're monitoring y?

I believe the short answer here is "No." The problem here is how long after it's closed is it useful to see? Every Customer (and possibly every User) would have a different answer here, and if you showed all followed Requests including closed ones you'd end up with an unmanagebly long list, because Users wouldn't get around to unfollowing.

I'm not aware of any plans to make changes here, although you could have a form with a Computer System filter followed by one with a Mobile Device filter followed by one for Printer, or even use branching to only select the relevant one(s)

@Berto2002 I would look at building a report in the first instance, although I'm probably not the best person to advise on which tables/joins to use, Reporting isn't my expertise.

Sorry, I may not have been clear - if you count the number of time the CI was used to raise a request you also have the number of times that IC/BP was run, so if: CI 1 uses IC 1 and BP 1 CI 2 uses IC 1 and BP 2 CI 3 uses IC 2 and BP 3 Then you've use IC 1 as many times as CI 1 + CI 2 have raised Requests, BP 1 as many times as CI 1 has raised Requests, etc.

Every Intelligent Capture and Business Process would normally be attached to a Catalog Item. Counting their use should be as simple as totting up the number of CIs that use them.

Again - no, that's not what Routing Rules are for. However, you may be able to adapt the information here: to extract it once within the Business Process.

That's the BP that will run, so you can set that to Resolve the request - either automatically or based on other criteria if required.

Hi @Adam Toms I was going to suggest reports as a potential solution but you seem to be ahead of me there. As for the workload, a compromise might be to schedule the reports so that the customers get a daily/weekly/monthly update rather than you having to respond to ad-hoc requests. I'm not aware of any planned changes in this area at present, but I'll make sure that the Developers have seen this post.

@JoanneG The Routing Rule would Raise the Request. It would then be up to the associated Business Process to progress it through to a Resolution.

I suspect that this is outputting the name of the Group rather than the ID, which is required by the assignment parameter. I haven't had the opportunity to test this yet, but outputting the variable to the timeline would be the quickest way to see what the variable contains.

I've tagged this as an enhancement, just so you're aware we have sight of this and it is being discussed but we have nothing definitive to report at this time.

Can you expand on what you're trying to achieve here. The Description field is TEXT and therefore potentially an unlimited amount of data, making this available to be freely downloaded could impact performance, which is the most likely reason it's excluded.

How is this outputted to Azure? ESP Conditions are an email function and show or hide variables based on an expression, I can't see how they would help here. If all of the emails end @nhs.net then you could ask for (and enforce with Regex validation) the firstname.surname format and append the @nhs.net where necessary.

The only idea I'd have would be to have them described as, for example, Victoria Ward [5CE] rather than 5CE - Victoria Ward.

Have you set the Measure to use GMT? If so, remove the timezone and resample, this should resolve the issue.

@SJEaton That would depend on the parameters of the node, but if you're populating the Service and Catalog Item parameters it'll take the BPM from there.