James Ainsworth

There is a setting that lets you turn this feature on or off. Keep in mind that this is a global setting and it will turn if off for everyone.

Hi Jim, The personal dashboards are just a graphical representation of the different requests that the user has access to. There are no rights associated to this so you are unable to turn this off. I'm curious about the use case for not allowing users access to this.

Maybe it is related to this... https://downdetector.co.uk/status/virgin-media/

Hi @samwoo Thanks for your post. There isn't any movement on this requirement at the moment.

Hi @Berto2002 Are these inbound emails being manually raised as requests, as that's what is being discussed here? Inbound templates are only used when an email automatically creates a request using the Routing Rules.

Hi Gareth, Thanks for your post. Are these 3rd parties not using the Customer Portal (for external contacts) which is separate from the internal Employee Portal?

Hi Damian, Try turning the following setting to ON. I'm guessing that the customer is only associated with one site and when that customer raises the request their site is automatically associated with the request. Because the customer only has one site, when you try to change it the list of sites is empty and it can't be changed. The above setting should bypass this restriction. When a member of the support team raises a request I believe that they have a little bit more freedom to say where the issue is occurring, which might be different from where the customer is located. I hope that helps.

Hi Gareth, I can only suspect that there is something in your default IC that is not being populated correctly when manually raising from an email compared to manually raising from the request list. Without being able to see your Intelligent Capture I wouldn't be able to tell. The error message Failed to log request does suggest that the record has not been added correctly which is likely due to missing information during the Intelligent Capture phase that is required for a request to be logged. One thing that can cause problems is when there are duplicate email addresses set against user accounts. For example, during the raising of the request, it looks up the email address to confirm which customer the email is from, but it finds two results and doesn't know which customer to assign the request to. This could then have a knock-on effect where it fails to associate with the service and a request catalog item because, with no customer, it can't check for subscriptions to the service. As suggested above, you may want to raise a support request with Hornbill.

Hi @Berto2002 Thanks for your post. This has been pointed out by other customers so it is likely to be corrected by the next update.

This role shouldn't give visibility to requests. The Service Desk Admin role will. Worth checking to see if any of the users have this. Personally, I wouldn't give users the Incident Management Full Access role. It does give these users the keys to the kingdom. If it is only for the sake of being able to reopen closed requests, then I'd recommend creating a custom role and just adding that right. That's correct. When you allocate one or more support teams to a service, only those teams can manage and view the requests raised under that service. Is there a use case here where a request has been raised to the wrong service and they are trying to assign it to the correct service and team? The roles do not have any control over individual queues. The visibility of requests is managed through the allocation of support teams to a service.

Hi Gareth, Thanks for your post. As you have a Premier Success Plan, for something like this it might be worth raising a support request. I don't have access to your data or the details of the issue so I'm unable to pinpoint what the issue might be. Here are some considerations that you can look into... The automatic raising of a request from an email using Email Routing does not use Intelligent Capture. As it is automated there isn't a person involved that would answer the questions, so it uses Email Request Templates to set some defaults on the new request. When it comes to manually raising a request from an email, it will use an Intelligent Capture script. There is a setting that lets you specify which Intelligent Capture script is used when manually raising a request from an email. If nothing is specified in this setting, I believe it will then fall back onto this setting and used what is specified here. My thoughts are that there is an issue with the Intelligent Capture script that is being used when manually raising a request from an email. It might be that the email doesn't have all the information needed to run through all the questions in the selected capture script. This is the reason for the setting app.itsm.progressiveCapture.newRequestFromEmail so that you can create a unique intelligent capture script to manage how requests raised from emails are managed. I hope that helps. Let us know if you have any questions.

Hi Lee, Thanks for your post. You have taken the right steps. I'm wondering if some of the users have more rights than they should. There are some roles that would provide this additional visibility. I would start by looking at one of the users that can see the requests that they shouldn't be able to and check their roles.

Hi Gareth, The Employee Portal is a view for subscribers to services. Even though the user might be part of the support team, if they have been set as the customer of the request, but they are not a subscriber to the service, they would not be able to see the request from the Employee Portal.

Hi Mark, I have come across another customer that was getting the same error message as you. They took the following steps 1. Add the right User.Read.All to your Azure config 2. Recreate the client secret Let me know if the information below helps... https://wiki.hornbill.com/index.php?title=Azure_User_Import#About_the_Hornbill_Azure_User_Import_Utility

This has been fixed and should be available as of Core Build 1917

Hi Martyn, Yes, a change for adding a search/filter to the Service Level Agreements view is still in the backlog. I had previously mentioned that it may be bundled with another change, however, it does now seem to be listed as a separate feature request. I'll let you know if there is any progress with this.

Hi Mark, Can you confirm where you are seeing this error message? I'm assuming that the error message that you posted is coming from the log file (Azure_User_Import_<date-time>.log) for the Azure import tool?

@Emily Patrick If you were to open KB0016716 does the content of the article contain the word "distribution" anywhere it in? I'm just trying to understand if you are getting results that shouldn't be here.

Hi Mark, Thanks for your post. I wanted to check to see if you have had any luck with setting this up yet. At the moment I'm not sure if the oauth2 config can't be loaded because it isn't configured properly or if there are some missing rights for the user under which the APIkey was created. Have you tried creating an apikey for the admin user or the same user that you used to create the KeySafe entry and test with this apikey?

Hi @Emily Patrick The search works by looking at each individual word that you type in and it will return results that contain any of these words. It doesn't take the entire string and look for an exact match. The problem with only showing results that have an exact match is that users will have to know exactly what is contained in the contents of the FAQ, and any deviation from the exact string would result in it not being displayed in the results. As suggested by Steve, removing commonly used words like "new" will help reduce the number of results. Looking at your results you may be able to use the term "staff" to narrow these down to what you need.

Hi @Isobellucas Thanks for your post. If this is only happening to this one user, their rights and roles probably need a closer look. As you have a Premier Success plan I'd suggest raising a support ticket as they will be able to look at the logs and backend data to investigate.

One thought would be to use this widget. I've not had a chance to look at this myself to see what exactly it provides. There is also the ability to share a library with the portal. There is more information on how to do this here

Hi @Jim Thanks for your post. Within the Hornbill Configuration, there isn't a way to apply a setting like this to all users. This is best done as part of the synchronization using one of the user import tools.

Hi @lomixture Access to requests is typically only accessible to a user if they are the customer or a connection on the request. While I've not tried this myself, as part of reporting you can schedule a report to be delivered to Document Manager and then possibly use the Document Manager widget that is available on the Employee Portal to provide access to these reports. There is a role called Docmanager Portal which would need to be assigned to all users. Do you think that this is something that may work for you?

If the user was to try to access the request by modifying the URL, for example, https://customer.hornbill.com/.../servicemanager/request/view/SR00039177/, do they get any type of message that they don't have rights to the request? Also, just to confirm, as mentioned above, canceled requests can't be seen on the customer portal.