Victor

@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

@AndyColeman @nasimg @Simulr the data service which all your instances are using did have some issues around 11:45 today and briefly afterwards. Our development and cloud teams are currently investigating the root cause for this. The services should be back up and running however until we establish the exact cause for this and implement some measures to avoid this you might experience brief downtimes (1-5 min).

@AndyColeman the error is sorted now, let us know if you still affected by this.

@AndyColeman we're aware of the issue and currently investigating

Yes... These are: a "No" answer to "additional external media" form; an inexistent answer to "additional external media" form because the form was skipped during ProCap. EDIT: sorry, I did not notice you replied already...

Correct. Correct, with an addition: no changes to a BP applies retroactively to a BP which is already attached to a request. Correct. (I think... a while back it used to do just that, restart the whole thing... nowadays it re-tries the failed step only) @DeadMeatGF @Paul Morrow as suggested, the "Restart BP" action works only in specific scenarios: the BP restarts if the error occurs due to an issue outside the BP itself. I'll give you an example that make this statement a bit more clear: Let's say you have an "Email" node with a mailbox or email address and it fails at this node because the mailbox or the email address are incorrect. You can go and change the mailbox details or email address to match the ones configured in the BP then you can restart the BP successfully. This because you change something to make it work that was outside the BP. Now in counterpart to give you an example where it won't work. Let' say you have a BP with a decision node with two branches, one if outcome is A and second if outcome is B. For some reason when teh decision is reached and evaluates the theoretical outcome is actually C. In this case the BP will throw an error as it does not have a valid branch to go through... You won't be able to restart this step because the change you would need to make is actually in the BP itself (adding an additional branch for outcome C). Hope this makes sense

@DougA we're sad to see you go... farewell and good luck on all your future endeavours!

@Stuart Torres-Catmur in a week, max two as far as I am aware... SM updates usually happen every other week unless there is a major functionality being introduced by an update... I don't think there is any in the next one so it should follow the regular pattern... Key words above are "usually" and "should"

@SJEaton you might not have to... If it works with a "No Match" branch instead of "No" then you don't need to rearrange the decision flow... Basically you need the BP to do the "internal only" evaluation IF there is "No" additional external media... (apologies if I make you process sound trivial ). I am saying this because if you do have additional external media, it follows a completely separate branch... Therefore what we/you are really interested is if we have a "Yes" answer to additional external media... if we don't have a "Yes" the we go and evaluate if internal only and further on this path... If we don't have a "Yes" this basically equates to a "No" answer or... no answer at all , in case the form was not completed during ProCap (i.e skipped). A "No Match" branch would cater for both scenarios... I haven't thoroughly tested any of these options, this is just thinking on how we can do this, if the above assumptions is not correct another alternative woudl be to simply add a third branch, a "No Match" branch just for the scenario where you don't have an answer at all... the "No Match" branch will follow the same path as a "No" answer.....

@Stuart Torres-Catmur thanks, just wanted to see if the behavior is the same as the one we identified recently. It is a defect, which has been fixed. The fix will be available in the next Service Manager app update.

@SJEaton is because the BP configuration in the particular scenario followed by this request during ProCap... I can try and explain this here but if it does not make much sense I am happy to go over this in a remote session... What I think it happens is that before "Internal Only?" decision (which is not where I think the error occurs), you have an "Additional External Media?" decision based on answers given in "External Advert" form in ProCap. However, because in your ProCap you selected internal only in the "Advert" form, the "External Advert" form was never completed... so the decision does not actually have an answer to evaluate... We can try/test this hypothesis if you change the "No" branch of "Additional External Media?" decision node into a "No Match". Then run another test request with same answers in ProCap.