Victor

@Kelvin mmm... you can get the number of open requests when the report/widget is run (which is like... now ) but I don't think we can the the historic data... we do not store historic status of a request, i.e. "on date X what was the status of the request" to be able to report on it... we only have the current status of a request, this is why the report woudl only work for the date/time when the report is run... However, if we only care about requests not resolved/closed and requests resolved/closed (so we don't care about onhold for example) we might be able to use resolved/closed date on a request to establish if the request was active or not on a specific date... if this makes sense... Otherwise, the only way I could see it working would be for you to keep a copy of the report ran each day....month...

For anyone interested, the above widget can be created using a custom SQL query like this one: SELECT ROUND(SUM(CASE WHEN DATEDIFF(NOW(), h_datelogged) <= 7 THEN 1 ELSE 0 END)*100/COUNT(*),0) AS '0-7 Days (%)', ROUND(SUM(CASE WHEN DATEDIFF(NOW(), h_datelogged) BETWEEN 8 AND 29 THEN 1 ELSE 0 END)*100/COUNT(*),0) AS '8-29 Days (%)', ROUND(SUM(CASE WHEN DATEDIFF(NOW(), h_datelogged) >= 30 THEN 1 ELSE 0 END)*100/COUNT(*),0) AS '30+ Days (%)' FROM h_itsm_requests WHERE h_status IN ('status.open', 'status.onhold', 'status.resolved')

@David Calder @pproot sorry to be a nagging pain but I am really, really curious how you resolved this issue

@SJEaton we're not getting rid of the custom fields on request, we might (emphasise on might) get rid of the "Extra Details" section on the service itself as we don't use it anywhere else. Custom fields and customising the details section of a request will be there and can be managed via the request itself...

@SJEaton so, as @Chaz mentioned, the "Extra Details" section is deprecated/obsolete. You need to use the details of teh request itself to add/remove custom fields. Also, it is quite easy to miss the "Apply Changes" button which is what actually saves the changes on the details section:

@SJEaton ah, I understand... it means the AR - autoresponder (routing rules) processed the email and it was automatically added to the request... in this case then no, the AR it won't process the attachments, is not currently designed to do so

@SJEaton I don't think it works using the service "Extra Details" ... to be honest I am not sure how "Extra Details" is supposed to work ...perhaps all fields added there should be available to all request types... Quick fix, on the request itself (rather than service), edit the "Details" section and add the "Start Date" field there...

@SJEaton if the user did it like this: then the email and any attachments will not be added to the request. If the user did it like this: then the email and any attachments will be (or should be, if nothing broken) added to the request.

@SJEaton does that someone uses the "Email" action from the request or uses the "Email" interface?

@Joyce not currently possible to have custom fields in requests table added to views

@SJEaton a good practice when having decision nodes is to always have a "No Match" branch... If a BP is rather complex then the flow logic must be carefully considered to avoid such scenarios... we do have a plan to introduce a "BP test" functionality that will simulate a BP execution and highlight any errors as such...but we don't have this yet EDIT: Almost forgot, we also have an experimental feature which, when enabled, will allow you to correct a BP associated to a request "on the fly". So, not all is lost, even if you encounter an error at some point it can be rectified to avoid the headache of recreating the request...

@SJEaton we have an outstanding defect whereby mapping static checkbox/dropdown to custom fields is not working... in the progressive captures where mapping to custom fields IS working, you have the same setup? i would try to create a dynamic list and use that in the filed.. instead of static...

@carlt nice!

@SJEaton I had a birt more thorough look into this also ran a few tests. I think I might have provided some unclear or misleading information...apologies First, forget about "Extended Information" variables, they don't work how I thought/expected... actually I am not sure at this point what/why are those used for... but this is something separate. So, if you create a custom field in request details it will use a custom field in requests table (custom_a, custom_b, etc.). If you have a custom form in progressive capture and a field in the form mapped to an "h_custom" field, it will use the custom fields in the requests table. So basically they overlap, and is intended behavior. To come back to your specific example: Employee Number, Job Title and Start Date will all have to be mapped the their own custom field.

@carlt hmm... indeed it seems the "getRequestQuestions" stored query will return a count() by default... right, in this case we can try this: <methodCall service="data" method="queryExec"> <params> <application>com.hornbill.servicemanager</application> <queryName>getRequestQuestions</queryName> <returnMeta>true</returnMeta> <returnUserMeta>true</returnUserMeta> <queryParams> <requestId><...></requestId> </queryParams> <queryOptions> <resultType>allData</resultType> </queryOptions> </params> </methodCall> If this still does not work there is another alternative...

@carlt most likely your API call is not returning any meta data... As you can see in the documentation the default value for the returnMeta and returnUsermeta is "false"... Basically your (most basic) API call XML configuration should look like this: <methodCall service="data" method="queryExec"> <params> <application>com.hornbill.servicemanager</application> <queryName>getRequestQuestions</queryName> <returnMeta>true</returnMeta> <returnUserMeta>true</returnUserMeta> <queryParams> <requestId><...></requestId> </queryParams> </params> </methodCall>

@carlt you can use queryExec data API to get the request questions... https://api.hornbill.com/data/?op=queryExec Application is com.hornbill.servicemanager and query name is getRequestQuestions. In parameters section you would need to specify the request ID: <queryParams> <requestId><request_ID></requestId> </queryParams>

@Paul Alexander is used to group nodes...for example if you have a sequence you use multiple times throughout your process you can put this sequence of nodes in a group. Then you can copy/cut it and it will do this for all the nodes contained within... Also is useful when you want to have complex BPs more "readable"...

@Kelvin can you detail a bit what you understand by "backlog"...just to make sure I get the full picture...

@Prathmesh Patel I understand is open tickets, my second question was if you need a In/Out SLA report for Response or Resolve? Or both?

@Prathmesh Patel one more thing... response or resolve SLA ? ... if you need both them might require separate measures/widgets/reports...

@Sonali I had a play around with widgets and measures and the best what I can come up with is a widget as per below (this is from your instance). I can't do a (pie) chart type because I can't use current pie chart functionality to get the data I need to do all the % grouping and calculations... besides, pie chart requires measures and measures can't give you current period data...

@Prathmesh Patel how do you define In/Out of SLA... is it on all active requests (open, on-hold, resolved) or just resolved? or just closed? I think is faster if I create a test widget for this in your instance and walk you through it after if you have any questions on it...let me know if is all right with you

@chriscorcoran I like to complicate things... otherwise where would be the challenge ?

@Prathmesh Patel did you manage to get the In/Out of SLA widget?