Victor

@ojenkins there is no variable to provide the last request update for the email template, I'm afraid... but certainly this could be looked into it as a future feature.

Also, if you like the timeline update to show this action I would suggest setting/changing "Update Timeline" from "Auto" to "Manual -> Yes".

@Michael Sharp the error occurs because the task expects a value for all time options (i.e. year, month, etc.). For your BP, if you like to request to be put on hold for 2 hours, then I suggest to set the time as 0 years, 0 months, 0 days, 2 hours, 0 minutes. I can see this configuration not being obvious (also not really needed to specify a zero time), so I will ask developers to look into this functionality.

I would also expect the path to include the current selected service when logging a request Our developers are now looking into this. I will also log an incident on your behalf in regards to this issue.

@Martyn Houghton IDOX Group I completely misread your post .. I'll have to think again then ...

@Martyn Houghton IDOX Group : Is this app setting turned on?

@nasimg I'll make a not that you experience this as well.

PATCH 2.29.5 This patch addresses an issue whereby the request list failed to load and eventually crashes the browser. This does not affect all instances as it occurs in a specific circumstance and also occurs only when using Chrome browser. If you are affected by this issue please update to this patch to have this fixed.

Currently being fixed... We have incidents logged for this issue so we will send you an update as soon as we have more information.

@Martyn Houghton IDOX Group this has been recently highlighted internally and is currently being investigated...

@gregmarcroftorc I'll log an incident for this, to investigate this further EDIT: incident raised, you should have received an email with confirmation.

Indeed, because there is no BP any more on these ones to perform the actual closure, the BP concluded/ended first time it was resolved/closed. Well, kind of, as I said is a bit of interesting one... basically the BP does something (i.e. setting the status to close) but this is not picked up by the request interface, unless the request is refreshed so the UI reads the current/new request values, it won't do it automatically as it is not designed as such... So from the request perspective (exclusively) it is not reverting a closed ticket... One of the things "resolve" action does is to set the request status to resolved...now, you can have something else (like the BP) which can set a closed status so in the end it will look like it reverts... but in fact "resolve" is acting as designed - to set the status to resolved... I will suggest our developers to make change in the resolve action to check for the request status prior to changing it to resolved... so if the request status is currently set to close, then the resolve action will prompt a warning or info to the user saying that it could not perform the resolve action as the current status is set to closed...

@gregmarcroftorc apologies, #spell fail BOP = BP = Business Process 488 has a service, but is not the service that manage the timers, is the business process... could be any number of reasons why the BP was not associated: service does not have a BP associated; if the above is correct then Service Manager will use the default process for the request configured on application settings but there is no process configured there; the process configured for the request or as default in application setting is not active. This could happen if someone is making changes to the request and saves the process without activating it. Saving the process will deactivate it by default so it needs to be activate either after s saved or by selecting the Activate option in BP editor (which will also save any changes made).

@gregmarcroftorc had a quick look at the examples you mentioned: IN00000525, IN00000858, IN00000838, IN00000813 - reopened - so they would fall under the first scenario (reopened scenario that I described above). IN00000561 - missing BP - would fall under the second scenario (missing BP scenario that I described above). IN00000479 - now this is an interesting one! This one actually followed the process, as intended and it would have been closed as any other "regular" ticket but... looking at the timeline I believe the following scenario occurred: call logged at 04/07 at 16:28 and progressed normally call resolved by analyst (like any other call) on 11/07 at 14:32:37 (second are important, you'll see why below) The BP did its thing as you can see at 14:32:38 set the status to Closed and at 14:32:39 sent the resolution email to customer. The timeline updates and the quick sequence shows that it could only have been the BP that set the status and sent the resolution email. The important part happened now. The analyst, Peter, still had the request open with action focus on resolution box. Because the request had not been refreshed (not to any fault from Peter by the way), the "Close" button was still "active" as resolve! Hope this part makes sense The UI did not know that the BP actually set the status to closed.... So when Peter clicked the "Close" button again, it changed the request status to resolved... as it usually does when the resolve action is performed. So basically it reverted the closing action that the BP just did! Now I imagine you woudl want to avoid this scenario in the future so I'll have a look and see what can be done, I'll get back to you on this... Meanwhile, may I suggest to let your analysts know that is sufficient to perform the "Close" action only once as the BP will do the rest (i.e. close the ticket) regardless of the UI status...

When 488 was logged it did not associate the BP.... most of the time I see this is because the service is not selected during progressive capture or the service doer not have a BOP associated... 704 does have this. Now, the BP is the one that caters for response and resolve timers. Because 488 does not have the BP the response/resolve was never started and stopped so the "SLA met" information would have never been stored... hence the missing info in the field.

@gregmarcroftorc I think I understand now why you have the "Resolve" button/action translated to "Close"... I am not familiar with the initial set up, but it kind of makes sense when I assume you had this translation as your BP will automatically close the ticket once it has been resolved. Therefore it would have been more meaningful for the analysts to see "Close" instead of "Resolve"... This being said, I don't really see why some of the tickets woudl have remained in a resolved state... unless... one scenario I can think of is perhaps the ticket was reopened... in this case, because the BP finished when it was originally resolved, when it was reopened and resolved the second time it would have stayed in the resolved state - the BP would have not been there to close it automatically. So unless the analyst would have closed it manually (unlikely since your analysts are not used to it since usually is enough for them to resolve it - translated to close) ... another scenario woudl have been if for some reason the BP failed to go past the "Await Resolution" node even if a resolution exists on the ticket... this would be a defect in my view... Sorry for the long and convoluted post, hope it makes sense I can have a look in your instance and see if I can find out why the 10 tickets remained in the resolved state and I would need some call references to investigate this... EDIT: following you post regarding missing rows for "SLA met/not met" report, another scenario for this issue might be that the 10 tickets do not have the BP associated. Following my above reasoning, the BP would have not been there to close the ticket so they would have remained in a resolved state....

@ljbrown our developers recently improved the Clean Utility tool to allow clearing down requests based on request class/type. Sill waiting to be released, they should follow up with more details soon

@Graham1989 we will log an incident for you and have a look at this behavior. The workaround I was referring to is remove "request category" and "resolution category" configuration for the services. Temporarily. Then you (your analysts) should be able to select the categories but you will see the whole tree structure (i.e. Incident and Change categories) but at least you will be able to select one for the moment...

Something that surfaced after 2.29... is related to the way the category is saved on request, whereby it will not retain all the structure... Is currently being fixed by dev. Had a quick look on you service configuration and it appears I can't see the same message displayed for resolution categories. Have you changed this?

@Graham1989 if you have a category level configured on service, for that request type, then you will experience this issue. This is something we recently found and was also reported by our customers ( @gwynne FYI). This is currently being investigated. As a temporary workaround I would advise to remove the category level definition in service configuration. No the most elegant solution as it will require analysts to go thorough the entire category tree to select the correct category but I hope it won't be too much of an inconvenient until we have a permanent fix. EDIT: just saw your reply now, this might be something different (for resolution category) . Above advise still applies fro "Request Category" where I can see you have "Incident" configured. I'll have a quick look to see about the resolution and get back to you shortly.

@Michael Sharp we have release a patch (Service Manager 2.29.4) to address the issue you experienced. We fixed your instance earlier on so this is not necessarily urgent, it can be done when you have a chance.

PATCH 2.29.4 This patch addresses an issue where analysts were unable to log, update or resolve/close requests if the analysts only have Incident Management User and/or Service Request User roles assigned. If your service desk analysts are configured to only use these roles for request management please update to this release.

@Michael Sharp as discussed earlier, this should now be fixed in your instance. This occurred because the roles used by your analysts (Incident Management User and Service Request User did not have rights to a new table introduced by Service Manager release 2.29).

@ojenkins you can click/select on the email on top then scroll down to the bottom of the page or keep scrolling to the last email you would need to select. Then on this one SHIFT+click to select and it will select all emails between the first one selected and the second one selected. Hope this makes sense

Dear all This morning we released our new version of Service Manager 2.29. This is now available for you to update in Hornbill app store. Below is a list of changes and fixes introduced by this version: NEW: Comments can be added to an existing workspace post through the Business Process Manager NEW: You can now specify the owner of a service CHANGE: Clickable links to posts and requests when the business process engine posts to a workspace CHANGE: You can create Views for requests that have a status of Cancelled CHANGE: Improved how attachments are processed when applying emails to requests. If the same file name is detected, the email ID and 5 characters are appended to the end as a guid. Only the first 50 are processed for performance, but this can be increased by changing the application setting servicemanager.email.maxAttachmentsToProcess CHANGE: You can now branch on catalog name in Progressive Capture FIX: There are now more checks to make sure that the correct request type is being raised via portals FIX: The resolve tab wasn't visible in some cases when looking at a request in the portals FIX: Users teams and supporting teams are considered when selecting closedByTeam, resolvedByTeam and reopenedByTeam FIX: The priority and team columns were missing in the export list FIX: Resolved an issue with incorrect results presented on charts drilldown FIX: Cannot unset drop down custom fields FIX: Changes to lists on board page not reflected when editing board details FIX: Unable to see updated resolution details in request timeline FIX: Showing database value instead of priority name when editing existing views FIX: Categories could not be unselected for services and the category form in Progressive Capture form was always showing an error FIX: Resolved an issue where resolved, closed, canceled published requests would still appear in portal search results FIX: Setting the initial priority to an existing request was not updating the timeline FIX: When looking at the expanded details of a service, the arrow was not positioned correctly FIX: Supporting Teams and Service Subscribers are now ordered alphabetically in the Service Details FIX: The Favourites tab on portals home page would grow slightly when you hovered over it FIX: Removed persistent validation error in the Schedule action FIX: If a message was too long for the autoresponder to deal with, it would not apply the update at all. Now truncating content so that it fits, link to the original email can be found under the 'More Actions' menu FIX: When printing a request, all of the sections are consistently formatted FIX: Showing friendly icons for all post types in the timeline of a request FIX: More information is given to users when there's a inactive or deleted Progressive Capture associated with a Catalog item. The Catalog item is hidden in the portals if this is the case FIX: Favourites button in Portals is now disabled temporarily when adding / removing FIX: When clicking on the email address of the customer raised by of a request, it will now check whether to use the built in email client or not FIX: In some cases, the Business Process Manager could not progress on resolution of a request FIX: When using the portals search, the list of FAQs wouldn't scroll to the correct one FIX: Escalation action details not correctly displayed in service levels summary FIX: Action buttons removed after copying custom filter with charts FIX: It was sometimes not possible to export the request list for certain date time columns FIX: If you had a service and a team in a views condition, it would only take the service into account FIX: Recipient was shown as undefined in some cases when trying to send email notifications to teams FIX: Business Process Manager broken for calls logged via Guest Accounts FIX: Removed ability to sort by department in Request List as it is not possible to do so FIX: Increased updated team ID column to 255 characters to handle longer team IDs FIX: Better appication handling if profileCodeGetList has no results in Service details > Request Configuration tab. FIX: Added an exception handler to handle a situation where a user does not have any groups (such as a system user like SYS:AUTORESPONDER) FIX: Name of board in boards list not updated after editing board name FIX: Improved the layout of the Portals Service view for mobile FIX: When the auto responder failed to find a match it did not always end gracefully FIX: Views were not always respecting the request types you have access to FIX: The wrong site is shown after a request has been logged, but editing reveals the correct one FIX: Questions are not being shown if you only have one question in a form FIX: If you specified the same condition more than once, it was not able to filter the request list correctly FIX: Response time list not refreshed when deleting the last entry FIX: Through selecting a Catalog in the Portals, Progressive Capture does not branch based on Service ID FIX: In some cases, the request type could not be selected FIX: The request list is not ordered properly by "Reopened" FIX: Connections customer selector is partially displayed in Internet Explorer FIX: On hold times are now shown in your local time format FIX: Improved how custom filters work when a user has no teams FIX: Profile selector shows a "no categories" message instead of being hidden when no categories are defined FIX: The site selection was not always updated if you changed it during Progressive Capture FIX: Timers now allow you to use any calenader as your default in Service Manager FIX: Resolved an issue with incorrect results presented on charts drilldown when services were used in the Views builder FIX: Counters against services in the portals were not round in Firefox FIX: Customer questions do not show for service requests in the Customer Portal FIX: Resolve tooltip now says "Close" when a request has been resolved FIX: Buttons in the On-Hold popup were different sizes to each other FIX: Different sized images were shown for customers depending on if they had or didn't have a profile image FIX: Contacts Organisation / Company is presented when applying an email to a request making it easier to distinguish between contacts with the same names FIX: Views now handle the Services and Teams you support, including requests with no Service or Team, when they are not defined in the view filter FIX: The Request list was too wide in the portals FIX: Requests tab against a service not shown in the portals if there are only closed requests FIX: Resolved issue when uploading restricted files during log request FIX: Improved code handling when the emails list is displayed FIX: When updating the app, if you've deleted the default asset types they will no longer be added back FIX: The ability to share a snippet with a team is not working