Jump to content

James Ainsworth

Hornbill Product Specialists
  • Posts

    4,928
  • Joined

  • Last visited

  • Days Won

    276

Everything posted by James Ainsworth

  1. HI Steve, Thanks for your post. I've replicated and now have the same BPM at the top of my list :). I'm sure that this will be an issue with the name and I'd suggest that we look for a fix rather than having anyone playing with the data. I will post back once we have heard from the developers. Regards, James
  2. If you are trying to store a URL in these fields, you could try a URL shortener.
  3. Hi @samwoo These custom fields... are these the custom fields on the service forum under the Extra Details section? James
  4. Hi Samuel, Thanks for your post. The originating purpose for the Frequently asked Questions (FAQs) was to provide a way of listing something like a top 10 list of questions asked against a particular service, and provide an answer to those questions. When looking at options for Sharepoint documents, I might lean more toward looking to see what we can do with document libraries. However, it might be that the document you have in Sharepoint fits the purpose of an FAQ. I would want to make sure we find the right mechanism for Sharepoint integration and not extend the FAQs too far away from their original purpose. Regards, James
  5. Hi @Martyn Houghton No update at the moment. It is still in line but not with development yet. Regards, James
  6. If there is more than one Service Level Agreement but no rules defined, the first Service Level will be used. If you have some rules in place, the order of the Service Level Agreements doesn't have a barring. If you are able to add a rule with no conditions, this is probably something that wasn't intended to be allowed. If a rule has no conditions, there is nothing to evaluate. The current way that this works is that if no rules are met, no SLA is applied which was done to cater for situations where a SLA is not required for a requests. The Routing Rules have similar logic where if no rules are met the message is not processed. If you want a particular SLA applied, if all other rules are not met, then the last rule needs to be a condition that is always met. We might in the future provide a setting to allow a particular SLA to be applied if no rules match. Regards, James
  7. @SJEaton From our perspective we do not know how the values of 0 were added. We don't have a fix to apply to remove these values. This might be more of a matter of cleaning you data. I will revisit with our developers in case something was missed. Regards, James
  8. Hi @Siobhan You are right with the BPM validation and publishing, but you will need to create a new ticket to test after each time you publish the BPM. Regards, James
  9. Hi @Kelvin First, it is great to hear your feedback and kind words. Many thanks. Regarding the Supporting Teams option on a Service, yes this has always been the case that if you don't select a specific team or teams that the Service is supported by all teams. This was done to allow for a more simple and faster setup. When there is an exception to the case and you want a more closed group of people working a Service, you would add the individual teams. It is important to consider what is being captured in the requests and if there is any data that you feel is sensitive and visibility should be controlled. With 30 teams, if you leave a Service set to be supported by all teams, this will also be reflected when assigning a request as all teams will be visible which can make it a bit more challenging for a user to know which is the right team to assign to. You may want to have the team assignments automated in the BPM as much as possible. At the moment, setting up Teams is done as you have described where you need to update the Organisation structure in Administration by creating teams and adding users to those teams. I will be interested to hear ideas and comments about this and if there is more we can do to work with Teams. Regards, James
  10. We have a change that has reached our development queue which will allow you to enable/disable the different request types for a Service. On the Request Configuration tab of a Service each request type will have a simple toggle to disable a particular request type. When raising a new request, if a user selects a particular request type from the Raise New options, only the services that allow for requests of that type will be displayed. If the Request Type form in Progressive Capture is used prior to the Service Form, again this will reduce the Services list to only show the services that allow for the selected type of request. As this is now with development, we should see this provided over the next couple of months. @DougA I'm also going to look into your original requirement where if you use the setting servicemanager.progressiveCapture.servicedetails.catalogRequired that Services without Request Configuration Items are not displayed. This makes sense if you are unable to select them anyway. I just need to be careful that this doesn't impact anyone's way of working Might also consider a setting on each Service where in the Request Catalog section of the service you could enable/disable this per service. Regards, James
  11. Hi @clampj At the moment the Site selection within the Description only seem to present the customer's site for selection. If you are not getting any results then this might be that the customer does not have a site associated to them. We do have a change in the backlog which will change this to allow for the selection of any site. I'll add you to the change. This isn't currently scheduled to be started on, but as a minor change hopefully it will not be too long before we get this done'. I'll update this post as it progresses. Regards, James
  12. Hi @Dan Munns This might be worth while starting as a new post so that it doesn't get lost in this thread and so we can track it as its own requirement. Third Party Services is something discussed before and having a simple link may be a nice solution to get this started. James
  13. Hi @Keith The ordering of Service is being managed in a different change. Updates of the progress for this feature will be posted here...
  14. Hi @Lyonel I also wanted to let you know that we have finished some development work to allow the Routing Rules to add a post to a workspace. This will be provided in an upcoming Platform update. Keep an eye on the release notes. Regards, James
  15. Hi Martyn, Do you mind if I ask how you are using the ordering of your SLAs or the reason behind having it in a particular order? Regards, James
  16. Hi Sam, I'm going to assume that this is still the case for you. Discussing with Developers and as mentioned before, 0 is not used in our code so we are not aware at this point how these fields would have been populated with this value. I was wondering if you have experienced any new requests that mark feedback as being zero (0)? Regards, James
  17. For now, something that might help is the Group Box. On a stage you can put your entire flow into a Group Box and then when the Group Box is selected and you use the ''Copy Selected Nodes'' option it will copy everything in the Group box. You can even have your workflows divided up into small groups to simplify your workflow if it is getting too busy... and then copy the Group Box to other Stages if you want to re-use the same nodes. Regards, James
  18. Hi @Claire Holtham Many thanks for your patients. I know that this has been a long time coming. I do want to let you know that we have completed some development work in this area which is currently going through testing, with the possibility of being available over the next couple of weeks, provided that there are no issues. The options that will be included are: Select the size of the Service Icons. The available sizes will be listed as Large, Medium, or Small in the Service Manager Settings. The default will be Large which is a similar size to what is currently available. Select the number of Services per page. The default will be 6 service as it currently is. This can be changed to any number. Zero (0) will remove the Show More option and just display all services. If it is likely that customers will have a large number of services, this setting of 0 would not be recommended. Adaptive Layout of Services. With the default 6 services per page, the layout will adapt to the size of the screen. If there is room for all 6 services to fit on a single row, this will be the case. On a smaller screen, these will adapt to multiple rows. Hide the Service's More Option. A setting will be available that will hide the ''More'' option displayed under each Service, allowing for more room and a cleaner look. Hide the Service's Description. A setting will be available that will hide the Description for all the Services, allowing for more room and a cleaner look. Hide the Request Counter and Impact. A setting will be available that will hide to two information icons that show the request count and the current Service status. If these are not required for your customers, this may allow for a cleaner look and feel. The result being that it can look like this with medium icons and no extra information, just the Service Name... and no 'More Services' button. While there is still plenty more that we can do to add to the Portals, I hope that this will be a step in the right direction and that you will find these additions useful. Regards, James
  19. Hi Martyn, We are looking to add to the filter options for the list of Services which will include items such as providing a filter by Service Category and eventually a Home View similar to the Request List. I'll look into the requirements for providing persisting filters for the Services List during your session and see how we can best deliver this. Regards, James
  20. Hi Martyn, There is an existing discussion on this topic. That post will be linked to our existing change in our backlog. It might be worth continuing the conversation under this same post. This is not currently scheduled for development. Regards, James
  21. Hi Mark, I can be worth having a look through the logic in the Routing Rules and compare with the contents of an email that wasn't raised automatically. If no rules are met, then the email will end up in the inbox. If the odd few are coming through this way then there might be something that needs to be tweaked. I recently had an example of this where I was testing for addressTo=''support@acme.com'' and once and a while the odd one didn't process as a request. I found that these emails had 2 recipients in the To field so my "=" was not picking them up as it didn't have an exact match. Instead I needed to have the rule addressTo like ''%support@acme.com%" . Regards, James
  22. Thanks for your post @Lyonel. I will discuss with our developers to see what the possibility is of providing this. Regards, James
  23. Hi Lyonel, There is a similar discussion here... Maybe worth continuing the conversation there to keep it all together. Regards, James
  24. Hi Dan, Nothing at the moment. I'll chase up and see where we are. Regards, James
  25. The challenge is between what information is captured in Progressive Capture compared to what default settings you have, followed by what actions occur automatically as part of a BPM. One scenario that I have personally come across is where a Progressive Capture did not include the assignment form, an application setting was assigning the request to a default team, but then the BPM did a reassignment to a different team. The confirmation box when I raised the request only showed the default team assignment from the setting, then looking at the request, it was sent off completely different. This takes away any value of having the confirmation box. As an unlimited number of things can be configured in the BPM and different progressive capture scripts can result in the same BPM being used I'm not sure if using variables would be the answer. There are just so many combinations. Variable themselves need to be populated and the timing of this may not provide the latest information on the request so there is still a risk of the confirmation box showing conflicting information which can lead to confusion. My suggestion is that at the end of the Progressive Capture you maintain the view of the information that you captured along with being presented the new Request ID. This way the request logger can see the information they added, without it being obscured by the confirmation box, there is no conflicting information presented to them to cause confusion, and there is still access to view the request to see the final result if they desire. Regards, James
×
×
  • Create New...