Victor

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

@chriscorcoran change display order to "Order by Status" ... it should display the unread messages on top (if sort criteria is ascending ^)

@chrisnutt I agree you do have a point regarding the "Raise New" button when you have progressive captures for each request type.... however the fact remains that "Raise Request" from an email uses the "Raise New" functionality, so you still need to have a progressive capture for "raise new"...

@Joyce currently you can't have distribution lists in Hornbill... an option would be to create this distribution list outside, on your mail server perhaps, and used the distribution list address in the node... this if the distribution list is static... if not then it will have to be multiple email nodes...

@SJEaton as far as I know this won't use the custom fields in the requests table, but the custom fields in the extended table (don't quote me on this, I am not 100% sure ) So if "Start Date" is mapped to relatedEntityData.record.h_custom_a then in the email template use this variable: Like I said I am not fully certain it works but give it a try...

@SJEaton if you already have the "Start Date" field in request details then this is already mapped to a custom field... or is it a new field you plan to add?

@SJEaton the Start Date field should be mapped to a custom field (like, custom_a or custom_b, etc.). Make a note of the custom field name then in the email template select this custom field from the variable drop down list... https://wiki.hornbill.com/index.php/Email_Templates

@pproot I understand that you identified internally the cause for the automatic refresh issue... when you have a chance, would you mind updating this thread with your findings? Thanks!

@nasimg yes there was a defect around changing a customer on a request, fixed in 963

This ^ the task could fail to create as the BP might not have the data required to create the task... adding a "Get Req Details" node prior to the task ensures the task has the request data... in case this does not resolve the issue, have a look in server service log files, it will give you an indication why the task create failed...

@lee mcdermott is just a coincidence that for @Martyn Houghton the print button is not working on imported requests. The cause of the issue is located in the timeline entries... As Martyn advised, it will all be working in the next update