Victor

@Stefania Tarantino are these 44 requests for the same service?

@HGrigsby https://www.hornbill.com/support/

@will.good @samwoo although this seems like an obvious option and something that should be there, unfortunately this is not very straight forward. I won't bother you with the technicalities (they are quite a bit of these in this area even if this is not apparent). We were looking for some time to enable this option on the webform however we do not have a solution that we are happy with at this time.

@Damian Roberts so, this? https://www.powershellgallery.com/packages/HornbillAzureIntuneAssetImport/1.0.0/Content/HornbillAzureIntuneAssetImport.ps1

@Damian Roberts https://community.hornbill.com/forum/132-integration-connectors-api-webhooks/ What API is that, what payload, etc... If the asset sub-state can be set from the UI then there is an underlying API that will set this value in the DB. We just need to find the right API and payload.

@John C do you want to prevent requests raised from portal or user app too? If just portal then you can disable portal visibility for the service(s) or you can set the catalog items service desk only. Disabling user log in via SSO achieves the same but it is a bit extreme... it will prevent users from log in Hornbill altogether...

@Jeremy I have seen the same on some of views in my instance, I have asked development to look into this.

@QEHNick Because time spent in task is a task functionality which is a Core item. Timesheets are Timesheet Manager app items and they only exist when the TM app is installed in an instance. Tasks (and their time spent functionality) will exist with or without TM app. Time spent in task existed long before TM app was created. You don't integrate them, with TM App installed you would use the TM time spent functionality. Without TM app you use task time spent.

@Berto2002 here. You would look for the "owner" in h_rel_type.

@samwoo tagged it as an enhancement

@samwoo right, so that's fine, it is confusing if "Intelligent Capture" concept is used on human tasks, given that we have an "Intelligent Capture" engine that is designed and works completely different than tasks, even if in some part, for a user, they appear to be somewhat similar on tasks. But yes, what you outlined above is not currently possible.

@chriscorcoran what roles does this user have?

I think there is a misunderstanding here on how intelligent/progressive capture works and what is intended for and how business process works and what is intended for. But no, you cannot have a value captured from a (random) task in a (random) workflow to be used as a value in a (random) intelligent capture in a (random) custom form and field... the "randoms" are because for what is described here, they are exactly that: random. Firstly, the PC is functionality that is used before a request is raised. It captures data from a user. The BP is functionality that is used after a request is raised. It automates and drives the request. Thus having "something" that we obtain in an "after" process to be used in a "previous" process is simply not possible. Second, we can then say sure, use the data from the BP to be used in the "next" PC... ok, but what is this "next"? Out of all the definitions you have in your instance, what PC would that be? And looking from the other perspective, in PC, from what workflow we would get this BP value? Is the data gathered in workflow 1, 2 or 3? This out of all the running workflows an instance can have... Perhaps a more practical example of how this discussion came to be might help understanding a bit better what we try to achieve here but using workflow data feeding capture data is impossible.

Not by using the task itself... As @Paul Alexander suggested you would need to store this value on the request (directly or indirectly) to have the human task value available in another stage.

@Dan Munns what I mean is that is the extent of what I can do on this Does this mean that I don't have a make it so button? Maybe I don't. Or maybe I do but I can't use it. Or maybe I do but I won't use it... possibilities... possibilities

@Dan Munns I can tag this thread as enhancement request but that's the extent of what I can do on this...

@Dave Longley what exactly do you mean by "adding in another additional language"? Only functionality I can think of is translations and you can add the Swedish translation in Platform Configuration: Switch the drop-down to "unsupported" to have locate Swedish, enable it and it will then be displayed as "supported" and can make translations in this language in user app...

@JakeCarter looking at the measure configured, would that be over 6 months? A year? Or since the beginning?

It can be built if requested... Sure... but there are other downsides or one more downside... in my view, the most important one that this functionality can simply disappear one day... not saying it will, no plans to do this as we speak as far as I am aware of, but the possibility is always there... so, my advice, once again, do not use this in a production capacity. Yes, I do understand it fills a gap in functionality... but the troubles of "fixing" workflows in case of this being removed might outweigh the benefits it provides now...

Are we talking about these Experimental methods? If yes, I would recommend not relying on them in a production capacity...

@Jake Carter not completely... you need :: Value Aggregate: Count This will remove Value Column as Count does not use this. Everything can stay the same. Change the value aggregate, resample and see what data is bringing then...

@Malcolm simply put, no. I do understand the requirement and where this comes from but current functionality does not allow this type of measurement. In addition to what Steve said above, all I can say there is to describe the reason for this, even if this does not help with what you are trying to achieve, at least it explains why. Request timers can only be started by the "Start Request Timer" nodes. There is no other functionality in Hornbill that will start a request timer. You can most likely imagine now that regardless of how fast the request is raised, workflow spawned, node executes... there will always be a difference (no matter how small, can be minutes, seconds, milliseconds)... not only between when the request is raised (date logged) but also from when the respective mail arrives in the mailbox (even if is automatically raised by routing rule, more if a request is manually raised). Moreover, there is also no functionality to "move" the start time for a request timer...

@SJEaton you have a "Service" and "Copy Service"... these two conflict. Set "Copy Service" to Ignore (as you specify a service already) and give it another try.

@Alberto M next Service Manager update

@Alisha what is a third party update in context of Hornbill? And how would this Third Party update the request? Directly/Indirectly?