Jump to content

James Ainsworth

Hornbill Product Specialists
  • Posts

    4,940
  • Joined

  • Last visited

  • Days Won

    277

Posts posted by James Ainsworth

  1. 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.

    image.png

  2. 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.

    image.png

  3. 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.  

     

    image.png

    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. 



     

  4. 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.

     

     

  5. 7 hours ago, Jim said:

    I've also noticed the 'Export Request list' permissions doesn't really make a difference

    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.

    image.png

  6. 8 hours ago, Jim said:

    Hi, is there any specific permission that relates to creating views and personal dashboards?

    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.

  7. Hi Damian,

    Try turning the following setting to ON.  

    image.png

     

    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.

     

    • Thanks 1
  8. 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.

  9. 7 hours ago, lee mcdermott said:

    most if not all analysts have the Incident management full access to enable them to reopen closed calls. Would it be this role that allows them to still see all calls?

    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. 

    image.png

     

    7 hours ago, lee mcdermott said:

    Also I have just realised that by adding a team to the supported team of a particular service has removed the ability of anyone on that team being able to assign calls to any other team?

     

    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?

     

    7 hours ago, lee mcdermott said:

    Is there a particular role or set of roles that allows an analyst to only see calls in their own queue but still able to assign calls elsewhere and re pen a call if need be? Or would i need to try and create a custom role?

     

    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. 

     

    • Thanks 1
  10. 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. 

    image.png

     

    If nothing is specified in this setting, I believe it will then fall back onto this setting and used what is specified here.

     

    image.png

     

    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.

     

     

  11. 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.  

  12. 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.

    • Thanks 1
×
×
  • Create New...