Victor

I did try this the other day and it did not work... I remember they (development) said something was broken in a flowcode... They must have fixed it and they did not tell me EDIT: @Michael Sharp can you follow the steps outlined by Tina and see if it works?

@Tina.Lapere you not doing anything wrong, is the progressive capture, it has it's own personality ... We did notice the issue recently (actually one of our customers did, but we like to take the credit) and is in attention of our developers to have it fixed. EDIT: Apparently we have a fix already Is being tested in our beta instances now.

@gregmarcroftorc there is no defect is just translation of the resolve action that says "Close" instead of "Resolve". So when the analyst clicks the "Close" button it is actually resolving the request, not closing.

All good then, happy this is sorted

This could be only a coincidence. What actually happens in your instance is that at some point someone changed the word "Resolved" to "Closed" via translation functionality. So when you see the "Close" button it it actually resolve. So probably this is why the requests not closed by BP will have a resolved status while the other ones will have a closed status because the BP is configured to close the calls. Have look in the admin tool: Home -> Service Manager -> Translations. Search for this key: user.view.request.details.resolve.resolve and you will see is translated to "Close".

When you go into the request, is the request showing as closed or resolved? Just trying to see if there could be an issue with the request itself or the list...

Hmm... that's odd...same error yet I did apply the changes... hmm... Right, I have tried one more thing, @ojenkins would you mind log off and back on and try again? Please try and test the AR update to a call that does not belong to you. You won't get a notification if you send and email and AR updates a call that you own

@ojenkins can you please log off then log back on? Then try another test? It would require your user to reload the associated roles to apply the changes I made ...

Had a quick look at a few requests in your instance and I think the reason why BP is not working is because the service is missing on these requests. BP are associated to services so if the service is missing so will the BP... This could be for the following reasons: the request is logged and service is not captured during progressive capture - make sure the progressive capture has "Get Service Details" form and it is set to mandatory so the analyst logging the call will not skip it by mistake; the service does not have an associated BP - seems to be configured correctly in your instance. But even if this would be be the case, if the service does not have a BP associated, it will use the default BP configured in application settings; the service is using catalog items to log requests (either analyst selects the catalog item or the request is logged via the portal where the only option is that catalog item) - could be a problem in your instance as the catalog item for SR does not have a process associated to it. This won't be such an issue if you at least would have a default BP in application settings (app.requests.defaultBPMProcess.service) but this configuration is missing also. My advice is to set the service detail mandatory in ProCap, set the BP on the catalog item and, as backup, have a default BP configured in application settings.

@ojenkins I did a bit of tweaking in your instance, can you have another try and test the notifications now?

Right, so it should be possible but it would require some changes to be implemented first...

@ojenkins just to double check, do you have these Service Manager application settings configured? guest.app.requests.notification.emailTemplate.analystAutoresponder - The email template to be used when sending a manual email or an email autoresponder update notification; guest.app.requests.notification.emailTemplate.groupAutoresponder - The email template to be used when sending a manual email or an email autoresponder update notification (if you use team notifications); guest.app.requests.notification.notificationType.emailUpdate - Notification type for automated new requests and updates to requests via email (configured to "email" or "both").

Actually, let me have a quick look into this, I think it is possible but I need some more information. I'll get back to you on this.

I don't this is possible with current functionality, it would require some new functionality to be implemented....

This I can't say, perhaps one of my colleagues would be able to advise in more detail

@Martin.bowman have you tried &[global["inputParams"]["priority"]]?

You can have carriage return in comments by pressing SHIFT + CR/Enter...

It's because the custom field value populated through progressive capture is not stored in the requests table, which is the table that provides values for variables in the template...

@Sean Burke the email template needs to reside in "Requests" category... Currently the BP does not know to look into "Service Requests" template category. Also it seems that some of your BPs are set to inactive so they will not spawn on requests until you activate them. You can toggle Active/Inactive from the BP list: Home->Service Manager->Business Processes. Look in the "Active State" column.

@chriscorcoran I think your process does this already from the looks of it? Call reopen -> update request -> set the checkpoint... and so on looping back to the "await call closure" task...

@chriscorcoran perhaps I am still not following your thought but, to reopen the call, the analyst will complete the task with the "reopen" outcome... then the task is completed so the timer on it will cease to exist. If the BP is configured to re-create the task when it has been resolved again, then this new task will "restart" the time, as it is a new task from Hornbill perspective... Is it here where the timer is not working?

I can see the challenge when you have a large structure of category codes... I was facing a similar dilemma when designing some internal processes. Perhaps this would be a helpful: Let's say you have a structure like: Tier 1 SubTier 1.1 SubTier 1.1.1 SubTier 1.2 Tier 2 SubTier 2.1 SubTier 2.2 SubTier 2.2.1 Now, instead of having a condition to check the category as: category = "Tier1 > SubTier 1.1 > SubTier 1.1.1" have the condition as: category LIKE "Tier1%" AND category LIKE "%SubTier 1.1.1%" where you only specify the top tier and the code itself or any combination of the above...

@Michael Sharp is all sorted now, you should not see this issue for any new logged tickets

The problem is with the email template used in the BP email node: LogServiceRequest. This template does not exist in the list displayed in: Home -> System -> Email > Templates.

Problem is that you will encounter this issue on the next 160 tickets.... I'll correct this later today, after 17:30 when no analyst are working in the instance.