Jump to content

David Hall

Hornbill Developer
  • Posts

    658
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by David Hall

  1. Hi @chriscorcoran, Apologies for there being no response when you originally posted. I have been following up on this scenario recently and currently the email content in this scenario is not something that can be configured via templates, the content is fixed. We have raised a change internally to look to provide the use of templates in future, however as an interim measure, as of our most recent build of Service Manager (build 966) the email notification sent when a customer updates via email will now additionally include the content of that update, so you should now get visibility of the customer update directly from the email. Kind Regards, Dave.
  2. Hi @Martyn Houghton Sorry about that, we are still expanding the documentation on this so I'll see about getting that added. Currently a "customer response" refers to one of the following actions performed on a request in the portal Adding a comment to a post Adding a post (update) Adding an attachment Confirming a resolution has worked Confirming a resolution hasn't worked Hope that helps, Regards, Dave.
  3. Hi @Keith, @nasimg Sorry it took a while, but I've tracked down the email and where this is generated from now. Unfortunately at present this email can not be sent using a configurable template because these emails have to be sent directly from the autoresponder account and can not go via a mailbox where templates could be used. An existing platform development request to enable the use of templates in such scenarios already exists, I have added you both as interested parties and I will chase it up, but I cannot currently give any timescales as to when that may be addressed. I've looked at what can be achieved in the meantime, and whilst I'm not able to include content from the associated request, it seems that I can update the current content that is sent to include the content of the email text within the notification email as you had asked for @nasimg so I will add this in for the next service manager build which is scheduled to be available in the next couple of weeks. Hope this helps, Kind Regards, Dave.
  4. Hi @lee mcdermott If the "run last step" didn't work then unfortunately there is currently no way to correct the BPM on the specific request. In your case of wanting to close such requests, provided you have the right to close requests for the type of request in question then once a request is resolved you should see a "Close" button on the resolution tab which will enable you to close it. Kind Regards, Dave.
  5. Ok thanks @nasimg, @Keith I'll do some more digging and see if I can find out what is being sent. Regards, Dave.
  6. Hi @Keith I've just been looking through the templates and code and the email you are referring to looks a lot like a template named "AnalystEmailUpdateNotification" which by default just states "Request {{.H_pk_reference}} which is assigned to you has been updated via email." followed by a link to the request. Could this be what you are looking for? If not then I'll go and do some more searching. Regards, Dave.
  7. Hi @Sonali You can use the Entity -> Requests -> Update Request -> Resolution Text process within an automated task as shown in the screenshot. Enter you own resolution text and choose to overwrite the existing resolution if required. Hope that helps. Regards, Dave
  8. Hi Hayley, As discussed in the following post, we have some new functionality currently in development which should help with what you are trying to achieve. Kind Regards, Dave.
  9. Hi @Sonali To take the request off-hold you can use the Update Request -> Status automated task as per the screenshot, if you set the status to "Open" then this will handle taking the request off hold as part of the status change. Hope that helps, Regards, Dave.
  10. Hi @Lyonel, I've just been able to access the log files for your instance and look to see what happened in terms of setting the data for the example request you mentioned above "IN00019039". I can see in the logs that when the request was resolved, 2 update calls were made, 1 to the data in the requests table and 1 to the targets table.. so at that point the data should have been complete and matching in both locations, there were no errors to suggest the update failed. If they are now empty as per your screenshot then I can only guess that they must have been reset after resolution? Were there any actions on that request after the resolution at 10:16? If so then I may need to look at those events to see if the values are reset, but the only place I can see that we would reset them is when changing an SLA. Regards, Dave.
  11. Hi @Lyonel, Thanks for that..will see if I can identify anything. Regards, Dave.
  12. Hi @Lyonel, I've tried a basic scenario of logging a request, marking the response, changing the service level, then resolving the fix time but this still populates all of the data for me. I can only assume there is a specific scenario which means the data is not being populated or is being reset. I'll try a few more things and see if I can identify how this may be happening. Regards, Dave.
  13. Hi @Lyonel, Sorry by "legacy" I meant that the first version of service levels in service manager was only ever allowed for 2 timers (response & fix) so the data was stored in the requests table. When we implemented the new version of SLM in service manager we altered the underlying structure to be more flexible for the future (hence the h_itsm_request_slm_targets table) allowing us the option to add more timers in the future, but we still had to maintain the request table columns for users of the original service level implementation. With all that said, having reviewed the flowcodes that record the response and fix times in the BPM (Application->Timer->Mark Response Time && Application->Timer->Mark Resolve Timer), both should still be populating the columns in the requests table that you highlighted in your image. I tried a very quick test locally and after marking the response the response data was present, and after marking the resolution that data was present. Perhaps you can try another test through to resolution and see if the data is marked?
  14. Hi @Lyonel, Glad you have the information you need With regards to the columns in the requests table, I will review why these columns are still being set for the response in your case, however there is no negative effect from these values being populated. These columns are used for the original legacy implementation of service levels where we only maintained a fix and response timer. When the current implementation of SLM (that you are using) was introduced we altered the data structure so that the target data was in its own table so that should we need to add more target types in future then we could do so, however we also needed to maintain backwards compatibility hence the columns remain in use in the requests table for some users. Regards, Dave.
  15. Hi @Lyonel, As you have already identified the data shown on the request details targets is driven from the h_itsm_request_slm_targets table. If you are just looking to identify how long the target took to be completed in seconds, then there is a column in that same table named "h_target_completed_duration" that should give you that data. If that is not what you are looking for then let me know what you are trying to get as an output and I'll see if I can advise on that. Kind Regards, Dave
  16. Hi @lee mcdermott, Just wanted to confirm if "RFC" is the Title or the ID of the process you are trying to use? The setting would need to match the ID which can be identified by going into the details of the process and viewing the process settings as per the screenshot. Kind Regards, Dave.
  17. Hi @Dan Munns Sure, happy to look at anything that may narrow down the issue. Regards, Dave.
  18. Hi @Dan Munns Thanks for the detailed post. I've tried to replicate the issue using your BPM process and based on the information above but I've not managed to do so at this stage. I just wanted to check whether this issue is occurring on every request you try to log or whether it was limited to the one case that you have reported? We'll continue to investigate further to see if we can find out what has occurred in this case Regards, Dave.
  19. Hi @derekgreen, As discussed previously in the following post, there was an unintentional change of behaviour around some request links in the most recent version of Service Manager, this will be reverted back to the original behaviour in the next update. Regards, Dave.
  20. Hi Keith, Thanks for the post. The scenario you have raised is something that has been previously mentioned following our initial release of SLM. A change request (CH00142587) has already been raised with the objective of allowing a Service to support multiple Working Time Calendars and Timezones in order to remove the need to have a different Service Level Agreement for each supported time zone. Regards, Dave.
  21. Hi @Dan Munns Sorry if I've caused any confusion with my previous response. If you previously had "Service Levels" configured and (as you have stated) not configured the new Corporate Service Level Agreements or Service Level Agreements against a service then the original service levels should continue to work as before (as detailed in the wiki note), you should not have seen any change in the application of service levels to your requests. If this is not the case (e.g. you are no longer getting service level timers on your requests) then please let me know and we can investigate further. In order to maintain use of both the original service levels and the new SLAs we altered the order of checks so it will initially try to see if the new SLAs are configured for use and if not then fall back to the original service levels if present, so even if using the original service levels, you may still see this error in the log.
  22. Hi @Dan Munns Thanks for post. I've found the cause of the error, I've raised a problem reference and I'll look to get a fix for it into a forthcoming release. In summary, this error only occurs when you do not have a valid service level agreement configured against the service being used in your request at the point at which your business process attempts to start the service level timers. I'm not sure if you have configured SLAs for your services yet (Service Details Form -> SLA tab), but the error will occur if: a. You have no SLAs configured b. You have more than one SLA configured but you have no valid rules which would result in none of the SLAs being used. If you do not yet use SLAs then the error will occur but will not have any operational impact, or if you are using SLAs then you will just need to check that you have either: - a single SLA or - a valid SLA rule configured to choose one of your multiple SLAs. Hope that helps, let me know if you have any further questions. Regards, Dave.
  23. Hi @Prathmesh Patel, I'm guessing you are referring to the content of an email sent when resolving a request? In that case you may just need to alter the case of the first letter of the variable names used in the email template that you are using, this is detailed more clearly in this post Hope that post helps, Regards, Dave.
  24. Hi Chris, I'm guessing this could be down to the ordering of your priorities. As shown in the attached image you can re-order the priorities by dragging and dropping each priority (with the highest priority being the item at the top of the list), so in my example it would record moving from High -> Low as an escalation and moving from Low -> High as a de-escalation. Might be worth checking first to see if that is the issue and if needed re-order as required. Kind Regards, Dave.
  25. Hi Keith, Thanks for the post, In the example you referenced, are you be able to confirm the source of the update made on the 28/11 that did not update the last update date? e.g. was it in the main client/service portal/mobile etc? Kind Regards, Dave.
×
×
  • Create New...