James Ainsworth

Hi @Berto2002 The actual "delay" is based on when the user logins next. If you have just assigned a role to a user and that role contains some rights to Service Manager, when that user next logs in, there will be a check done and the user will be automatically assigned a subscription. There is a setting called subscription.application.allocateOnLogin that enables or disables this feature. If you don't want to wait for the user to log in after assigning the role, you can manually assign them to the subscription user list under the Service Manager configuration.

Hi Cassie, I believe that this may be something to do with the adaptive screen sizing. The forms are defined to re-align based on screen size so that you could run the full app on something like a tablet. This is what I get on my large desktop monitor, but like you when I view using my 14-inch laptop monitor it leaves some white space. I'll feed this back to the development team.

Hi @R Hicks Thanks for your post. The URL https://live.hornbill.com/<instance name>/catalog/service/com.hornbill.servicemanager/29/ is a link to the Employee Portal as seen by a service subscriber. Have you checked the portfolio status on these services to make sure that they are set to Catalog? If it is set to Pipeline, it won't be available in the service catalog for subscribers. Having system admin rights doesn't necessarily give you full access to different aspects of any application within Hornbill. It does however give you the ability to add rights to yourself in order to access different areas. I'd recommend not using the admin user or providing admin rights for a regular user account that's used on a day-to-day basis.

Hi @DRiley These will be times that were previously selected by the user. It is simply a way to quickly select times that you commonly use. Hope that helps.

To get the date from the authorization, you should be able to use the Get Last Authorization Details or Get Last Authorization Details By Node.

Hi @Ashley Thanks for your post. If you have access to the date/time of the authorization through a variable, then you should be able to use the Date Formatter to convert it to just a date. Let us know if that works for you or if you need any more information to set this up.

Hi Ade, Thanks for your post. As mentioned, you can't go back to previous stages in a workflow. You will want to make sure that each stage is designed to fulfill a set outcome before continuing to the next stage. For example, if your workflow was regarding a change you may want to start with a stage that collects information and have all approvals complete before continuing (you could even lock up the information in the change after it has been approved to prevent the details from being altered). The next stage could be the implementation stage where it gets handed off to someone or a team to do the work. It might be that you have some form of acceptance for the completed work, and if rejected it should be managed as part of the workflow within that stage. In some cases, people may find that a multistage workflow isn't required, and they would rather have all the workflow in a single stage which would allow them to easily repeat parts of the workflow if required. Hope that helps.

If there is an existing contact within a supplier you can hover over the contact name to see the ID as part of the URL.

Hi Frank, Thanks for your post. I've done a test to get at least one record into the staging table. From what I can see, both the supplierContract and name fields are required. Can you confirm if you have a value in the name field?

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.