Victor

The issue with Show Service Request Items option on My Services widget not displaying catalog items for services on a domain page on employee portal has been identified as a defect and a fix will be included in the next Core update.

@Cristian ok, so this user only... right...must be something with this user that I am missing... let's take this in private message

@Cristian is it just this user or also other users having same roles?

@will.good all questions such as "How Do I... " or "Why" regarding functionality are handled via the forums. On a closer inspection, on this occasion we must apologise as I believe we misunderstood your support request where you have highlighted a possible issue with designed functionality which is now being discussed with development. So to answer your question as to "Why is this not showing the Services with the drop down catalog items?" this does not seem to be an incorrect configuration issue, but rather a defect with the services list content (that should be displayed there) when having the "My Services" widget on a domain page. I will reactivate the support request you have raised with us and will update you with investigation outcome.

@billster you cannot, the autoresponder does not have such functionality. As Steve advised, autoresponder will simply raise or update a request without any changes to the email content that will end up in the request.

@Cristian what roles does this user have?

@Adambingley sorry, I don't have an ETA

@Paul H the fix mentioned here was deployed Thursday (04/08). As far as we know and based on feedback from affected users, the fix addressed the issue(s).

@Adambingley I think the Update not working was a defect confirmed by development. We have a fix ready, afaik it will be included in the next Core UI update.

@Paul Alexander Unlikely. That "recent issues" thread is specifically for service portal, not live.

@Mark (ESC) Not that we are aware of... What portal are you using? live.hornbill.com/... service.hornbill.com/... customer.hornbill.com/... Can you please download the PC definition file and send it to me via private message.

@sprasad do your users still have the issue you reported? Please use the support webform if that still persist for us to investigate.

@AKetteringham it can be the account being suspended to repeated unsuccessful login attempts or a user import that sets the user to suspended (depending on configuration and such). If you say this happens "randomly" I would think the latter would be a probable cause.

@Paul H some more details on this issue if you like to know more:

Some of our customers have reported and have been affected recently by a set of issues with progressive capture when using the service portal. The range of issues varied from captures not loading when using the catalog item, captures progressing to a certain point at which the capture because unresponsive, and or users being unable to complete the capture as it once again became unresponsive. The issue appeared to be intermittent, affecting some progressive captures but not others and occurring at apparently random intervals and having captures manifesting the issue just for same captures to progress with no issues when tried at a different time. As you might imagine, the nature of the issue and the behaviour proved to be a bit problematic and posed a range of challenges for our support and development team in investigating these issues. When we began our investigation, the main challenge we faced was in replicating the issue in a local instance. Replication would be the first approach in troubleshooting as it can provide the most information about an issue and how it can be addressed. Despite the initial efforts the issue did not manifest for support and development teams locally and what was soon proved to be more problematic was that the issue did not manifest for us when following the exact steps and using the same user context in a live instance. This would be one of the worst outcomes in the initial investigation as it does not give any meaningful information as to what the possible cause would be. The next approach was to look at how the functionality is designed and build to see if anything can be identified as the potential root cause and direct investigation efforts into these areas. The caching mechanism was first identified as a potential root cause. This was due to the fact that on some occasions clearing the HB data cached in the browser resolved the issue for some users but either this did not work for other users or for the users that had it resolved the issue started manifesting again after some time. While this clearly indicates there is something with the caching mechanism, we could not exactly establish if the root cause lays in this area, and possibly there is some other mechanism behind the caching mechanism that is causing the issues. During the investigation at some point, we did manage to replicate the issue locally which was very beneficial for troubleshooting efforts however, this was quickly shadowed by unexpected behaviours. While the support team could replicate the issue reliably, the development team using the same instance, same user and the same capture could not. The next approach was to do a code review of the PC engine, we identified the key information which eventually allowed us to find the root cause for the issue and how it can be addressed. One of the actions performed by the PC engine is to load in the browser a set of JS (Java Script) modules. Among many things, these modules are responsible for the PC functions such as loading the forms, defining the behaviour of the Previous/Next buttons, or defining the behaviour of the Finish button. If these JS modules are not loaded in the browser when the PC initiates, then the PC will not effectively work and it will generate issues such as the one experienced here. The key piece of information here was that one of the main modules would only be loaded IF the capture was containing a standard Service Manager form, these being the default forms that can be added in a capture when designing it. Soon after we started to look and see if the captures that we knew were causing issues had any of default forms and we found that in fact all of them were comprised of only custom forms. Based on this information we have immediately created a set of test cases that eventually replicated the issue in the exact form and manifestation that was initially reported. At this time development is addressing this scenario and a fix is in progress that will be deployed in all live instances as soon as possible. This has been a challenging investigation to identify the issue due to the aspects described above. We unreservedly apologise for all the troubles this has caused you and your users. If you have any queries or questions please let us know.

@Paul H We definitely had some progress on this, we should have a fix ready and deployed a bit later today. Please bear with us.

@JanS2000 the issue reported in this thread with characters < and > not displaying as such in the timeline should have been fixed in SM build 2091 deployed in Dec 2020. Can you please detail on the issue you experience now, perhaps some screenshots? (please remove or obfuscate any sensitive data from screenshots)

@Paul H yes, not very recent (like yesterday) but recent...

@Paul H we are aware of some issues on the service portal including the one you experience where the Finish button is unresponsive. We are actively investigating these issues.

@samwoo I might have not been entirely correct (which I will never admit) but you actually do need to have a template created under specific request type (e.g. Change Request) if you want that template to use variables that are specific to that request type (e.g. Change Request). This template can then be used by workflow automations but cannot be used when emailing from a request, that part of advice is valid.

@samwoo I'm afraid enhancements are out of my hands. You need devs and product managers to take this forward...

@samwoo templates that you would need to access on requests (regardless of request type) have to be created for "Requests". Yes, as per above, they won't work, they will not be visible/accessible if they have not been created for "Requests".

@SJEaton you can try my first suggested approach where you put the main request in a semi-permanent suspend state, only resuming briefly at certain intervals and performing various actions (e.g. HUD update) based on what even triggered the resume. I think at this point it would be more beneficial if you can discuss this in more detail with a product specialist to cover the complex aspects involved here and perhaps identify a different approach that could work better.

@Jeremy you can discuss this with Hornbill Customer Success if you like, I merely advised on a knowing issue that is being addressed.

@davidrb84