Jump to content

Steven Boardman

Hornbill Product Specialists
  • Posts

    2,316
  • Joined

  • Last visited

  • Days Won

    137

Everything posted by Steven Boardman

  1. HI Martyn Thanks for the suggestion, it is not currently on the list of available variables however it is the intention to expand those which where initially provided, and this seems like a good candidate. We will probably look to tackle extending the available one's when we have a few more which we can group together and tackle in one go. To that end I would be interested to hear anyone else's thoughts on other variables they think would be useful to be available with our Snippets feature? Thanks Steve
  2. Hi Martyn Thanks for reporting this. The issue was reported by another customer, and has been fixed and will be released to live in SM 2.26 in the next couple of days. Regards Steve
  3. Hi Ralf The linking of requests, and defining the different relationships, along with the cascading up and down and automation options is an area we are looking into and we will update once we have some more news in this area Thanks Steve
  4. Hi Ralf We have been able to replicate the behaviour with the Connections action icon and a defect has been raised for this with a high priority. In regards to the Solutions action icon, if this is configured to show on a Service and Incident type, it will not be visible until the Incident is linked to a Problem or Known Error which has a Workaround defined. Once the Workaround is visible, the Solutions action icon should be visible to any linked Incidents, showing the workaround as a possible solution to the Incident, which the Incident owner can accept or reject. Could you let us know if the solution action icon is not showing even in the above scenario? as we would not expect it to show on an Incident form otherwise. Thanks Steve
  5. Hi Martyn Just to add to this, we do have a development we will be starting shortly which will allow you to define custom / sub statuses per request type per service, against these you will be able to define actions such as, if the request is updated from self service that the request can be automatically moved into another of your custom sub statuses, with other notification options - now this does not go as far as creating a task for the owner to do something, but the configurable status changes I would suggest from something like With Customer to Awaiting Owner Action would help a little,. There is more depth to this particular development, around interactions with the pausing of timers, but I thought it might help to give you some visibility of this planned change as it was an example you cited in the initial post. Thanks Steve
  6. Hi Martyn Thanks for this suggestion, this is something we will be looking to implement it is just a case of scheduling this in, we will update here with updates. Regards Steve
  7. Hi James Following our conversation earlier the developers have found an issue and a fix will be available in our next release of Service Manager, hopefully next week. Just to give you some context here. We introduced functionality a few updates back which allowed you to within your organisational structure associate specific sites to specific Company groups under your organisation. Now having looked at this you have a Company group of Hoare Lea which all your users are assigned too. In some organisations there is a need for multiple Companies to be defined and each of these Companies may have their own specific set of sites associated to them. On the request form the logic should only show sites specific to the company which the request is logged against, in your case this would always be Hoare Lea.On investigation it appears that All Sites, datacente and Pune are in fact linked to the Hoare Lea company group and the other 14 sites are not. You are also seeing the Site for the specific customer. We have identified an issue and this has been fixed and will be available shortly, as if no Sites are linked to any specific company grouping in your organisational structure then all Sites should be returned, now until this fix is released if you need to ensure all 17 sites are visible from the Sites pick list on the requests you can associate each site to the Hoare Lea company grouping (this is a short term suggestion until the release is available). You can associate these from the admin tool. Home > System > Organisational Data > Sites and under each Site populate the Company field. This should then allow you to see all sites on the request sites option, assuming all your staff are linked to that company group. Once the fix is applied you can remove the sites from the company group and they will still appear on the request list. Sorry for any inconvenience this may have caused. Regards Steve
  8. Hi Samuel Thanks for the post. Have you considered using boards for exactly this purpose? Here you can define the lifecycle stages of your change process, in the Board lists. Using the Business Process Engine, you can automate the moving of requests across the change lifecycle as the tasks and stages are complete. Giving you a real time bird's eye view of all changes in flight across your change process? This is equally applicable to any other process. Here is an example. Boards can be shared with teams and individuals and here is some useful reading to get you started: Boards: https://wiki.hornbil...x.php/My_Boards Business Process Automation, specifically the Boards content under Nodes: https://wiki.hornbil...rocess_Workflow Does this help? Steve
  9. Hi Tony Just a quick update on this one, the option to automatically schedule a change has been added and will be available in a Service Manager update in the next couple of weeks. This option via the business process engine will allow for the automatic scheduling of the change with definable start and end dates in the format (Day / Hour / Minutes) after the creation date of the Change. Thanks Steve
  10. Hi Kelvin The Context Variable Picker which Neil and the team have been working on is now available in the Admin tool. This will allow you to map the answers from a progressive capture custom form questions to the Summary and or Description fileds of the Request, amongst other benefits. In order to use this, ensure you use the Get Information > Request Questions node ahead of the Update Request > Details Node. Ensure you specify the formid in the Get Information > Request Questions node configuration so that the correct custom form questions / answers are then available in the Update Request > Details Node. Open the Details node configuration and in either the Summary and or Description text boxes select ctrl and left mouse click to reveal the Variable menu picker, select Flowcode Outputs and then select the question you wish to insert. I hope this helps Thanks Steve
  11. Hi Martyn The next Service Manager release 2.26 which includes the Respond / Resolve values is currently going through the release cycle and testing phases from Dev to Beta to Live, this needs to follow due course but if this goes smoothly I would anticipate this being pushed to Live early next week if not a little sooner. Sorry I can't be more precise but this is subject to successful progression through the various release stages. Hope this helps Steve
  12. Hi Martyn Thanks for the post and use case, we are doing a few things in this area and I hope this information helps: 1. It is possible as you say to take answers from progressive Capture custom forms and using the Get Information nodes in Business Process use the answers to branch, but as you say if you have medium to large progressive capture flows, and branching this can involve some planning in the business processes in order to capture and manage each possible route which could be taken and the different custom form answers. 2. We have introduced more Get Information options, to allow you to not only evaluate Progressive Capture Questions, Request Details but also now Information from either the Customer details, or Organisation details for the request. 3. You will shortly see an option to insert request variables via a menu control. This will allow you to include request variables in tasks and authorisations but also copy the answer from progressive Capture custom forms questions into the Summary and or Description Fields of a request - which can be evaluated and or included as variables in email templates. 4. We have a development story we are just starting which will allow for the mapping of progressive capture custom questions into request custom fields. This will perhaps provide the flexibility you are after, as this will still allow the flexibility of your branching in Progressive Capture and the use of custom forms, but it will allow you to populate the custom fields of the requests, with the answers from the questions in the different custom forms. Then you can more simply evaluate just the specific custom fields needed in the business process engine, rather than factoring in all the possible custom forms which are used depending on the branching. An additional benefit of this mapping, will be the ability to include the mapped 'questions' into the custom fields of the request, so they will be available as variables to use in email templates. I hope this helps and watch this space re the release of the mapping feature mentioned in point 4. Thanks Steve
  13. Great no problem Just as an aside, the Teams configuration manages visibility in the request list, but also in the assignment options on the request list, and in requests. So if you wanted to limit which teams can view requests logged against this service, or if you wanted to restrict which teams appear in the reassignment lists then this is the option to use. This is perhaps more applicable where you have multiple different business areas using Service Manager, say IT, Finance, Marketing etc and you wanted to keep some degrees of separation between them in lists, and assignment options, and when creating views and content for your personal dashboards. Cheers Steve
  14. Hi Gareth Thanks for the screen shot. The 'This Service is available to everyone' is the default position for all services, and is the expected behaviour if you have not defined any subscribers or if you remove any existing subscribers. If you remove a user, or team from the Subscribers then the service will be visible to all users. The Teams where you have Applications York defined has nothing to do with the subscription to the Service. This is entirely concerned with which of your support teams have the rights to view requests raised against Application York - Known Issue Service from the request list. If you want to manage your subscriptions to a service by team, and here I am talking about the end users and their visibility via the Service or Customer Portals, then you would need to define the team in the Subscribers section. I apologise again if I am misunderstanding your issue, and my comments are along the same lines as my original comment, but I am seeing this as you maybe confusing the Team setting where you have Applications York defined and anticipating this having a bearing on the Subscription which it doesn't. I can see your running the latest build as you have the Bulletins feature visible, so I am hoping the above makes sense, if not please bear with me and if you could re-affirm the behaviour you are expecting? Thanks Steve
  15. Hi Gareth Would it be possible to share a screen shot of the service configuration view? Thanks Steve
  16. Hi Gareth Thanks for your post, we are just completing a development which will extend the export limits, by default this will raise to 1,000 however there will be a system setting which will allow you to increase this further, we are going through testing up to 10,000 records and once this is complete it will be available in an update in the coming weeks. Regards Steve
  17. Hi James Thanks for the post and the suggestion, we are always looking for ways to improve Service Manager, we'll take a look at this and see what options we have. Steve
  18. Hi Chris Thanks for the post, and I can understand the challenge you may be having here. Currently the Priorities are used to control the resolution timer's and as such it can become quite a long list which can result in the problem you describe. We are currently finishing development on new Service Level Management functionality which will allow you to set response and resolution targets on much more granular options rather than just Priorities, which I hope will allow you to reduce down the number of Priorities to a much more manageable level. The new functionality will allow you to configure global Service Levels Targets (response and resolution targets in the initial release), which can be used across the different service you offer. In conjunction with this you will also be able to configure Service Level Targets specific to individual Services you offer. Each Service Level Target you configure can be set against a different set of operational hours. On each Service you will also have a Rules Builder for the Service Level Timers, which will allow you to set multiple rules checking for example which organisation, group, customer the request is raised against, which Catalog Item, and of course which Priority. This will allow you to use the rules builder to manage if you have different Service Levels for the Different Service you offer, and if you offer different response and resolution targets for different customers, organisations, groups etc rather than relying solely on the Priority list, and each time you need a new resolution target you currently have to add a priority to enable this. We are hoping to role out the new functionality quite soon, so please watch out for Harry Hornbill notifications once this is available. In the short term one suggestion I could make is that you could look to reduce the need for analysts to pick the Priority as part of the logging process by building some logic into your supporting business processes. What I mean here is if you are using the Request Catalog functionality you can link a specific fulfilment process to each item, and in doing so you can use the Request Entity > Update Request > Priority to preset the correct Priority which should be invoked when a customer raises a request against that specific Request Catalog item, you can also use this to preset the logging category and other request attributes which are specific to the catalog item so you don't need to ask these questions during the associated progressive capture. It is also possible to use the Request Entity > Get Information operations to evaluate who the customer / organisation is or even attributes of the customer / organisation / request followed by a decision node and custom expression to then set the priority correctly based on a specific value or flag for the request. An example being if you have stored a value in a custom field for an organisation which will determine which level of service they should receive when they raise against a specific service or catalog item you can evaluate that value and set the appropriate priority and in turn the correct resolution target. Useful resources: Request Catalog: https://wiki.hornbil...Request_Catalog Business Processes: https://wiki.hornbil...rocess_Workflow specifically the Get Request Information operations I hope some of this is helpful and please watch out for Harry's notifications in the coming releases regarding our new Service Level functionality and rules builder Thanks Steve
  19. Hi Chris Thanks for your post. It is not possible to change the Service once the request is logged, it is of course possible during progressive capture and the logging experience to alter the Service against which the request will be logged based on the information from the customer. The Business Processes are driven by the Service and move forward through the various stages that you have defined. It is possible to loop through process activity (tasks / outcomes) etc in each stage but not to go backwards to previous stages. One approach which may help is introducing the Request Catalog items against the Services you offer. This will allow you to be more granular about exactly what each Service is designed for and the specific request catalog items which are available against each, thus reducing the number of incorrectly raised requests? In the example below against my Mac Support Service, I have broken this down into the specific request options which can be selected in relation to this service: Learn more about the Request Catalog here: https://wiki.hornbil...Request_Catalog We are always looking at ways to improve our Service so do let us know if this would help? Thanks Steve
  20. Hi Graham Thanks for your post. Service Manager provides functionality to speed up the logging process for repeat calls and I would suggest their are two areas to initially look at: 1. Request Templates - Available from the Incident and Service Request Progressive Capture forms, users with the Service Manager Admin role will see the option to configure Request Templates and predefine the values which will automatically be populated into the Progressive Capture forms when a Request Template is chosen by an analyst using the Incident and or Service Request options (These are not available for Change, Problems, Known Errors or using the 'Raise New' Progressive Captures). Create from here: Edit here: Use from Here When editing the Request Template forms, the available questions will reflect the progressive capture forms you have defined for your Incident and or Service Request Progressive Capture flows: More on Progressive Capture here - https://wiki.hornbil...apture_Workflow Please also consider you can combine the presetting of the requests fields both from Progressive capture but also from the Business Process which maybe invoked once you raise the request using a request template. The business process may give you the option to automatically move the request into a resolved or closed status and or use the the Update options to set request values. Check out the Update Request options available in our business process engine here: https://wiki.hornbil...rocess_Workflow 2. Request Catalog Items This option allows you to predefine the request catalog options both for Incidents and Service Requests that either the Analysts when logging a call can choose from or your customers on the portals can choose. These allow you to be specific about what service options you provide and each catalog item can have it's own Progressive Capture script with it's own questions, and it's own fulfilment process. I mention these as this is a very simply way to raise a request, and if you can define the types of issues you receive you can use the business process underpinning each item to preset values on logging like - Priority, Summary, Description, Logging category which saves the analysts / and customers from having to enter these for known issues or requests. Learn more about the Request Catalog here: https://wiki.hornbil...Request_Catalog Check out the Update Request options available in our business process engine here: https://wiki.hornbil...rocess_Workflow I hope this give you some ideas and points you in the right direction Thanks Steve
  21. Hi Mark Thanks for your post. We are always looking for ways to improve the intuitiveness of Service Manager, so we will take this suggestion away and post back once we have an update on how we can improve this experience. Regards Steve
  22. Hi Thanks for the post. I have not been able to replicate the issue. If you are worried about subscribed users seeing this service via the portals you can move the Service into either Catalog or Retired portfolio status which will ensure nobody sees the service on either portals, or through the Services form on Progressive Capture in the user app (Analyst view). Could you provide any replication steps? or a screen shot? Bear in mind the default position for any service is 'The Service is available to everyone', but are you saying you are seeing the above message and the their is a Team subscribed to the Service? Could I ask if you added the Team to the Subscribers list or to the Teams list above? if it was to the Teams list, this is not for subscribing team to the Service, it is to reflect which Support teams support the Service. This will allow members of those Teams to view requests raised against the Service on the Request lists, and also only those teams will appear when using the reassign options on requests raised against the service. You can use the Subscribers list to add users, groups, teams etc to the service so that members of these can view the services on the portal and make requests against the services they are subscribed too. Wiki references for the above: https://wiki.hornbil...ex.php/Services > Service Visibility Section. Apologises if this is not the case, but I just wanted to try and cover off the various options I could think of. Thanks Steve
  23. Hi Kelvin Thanks for confirming the requirement. Unfortunately it is not possible to use the variables in the Update request node operation, this is currently just used in Task and Authorisation nodes. We have the change you require in our immediate queue and as soon as this is available we will post back and let you know it is available. Thanks Steve
  24. Hi Martyn Thanks for the label feedback I have requested this is altered. These do correspond to the existing Start on, Due on options. The additions of the Respond By and Resolve By have been added to the Get Information list but these will need to wait for the next Service Manager release to go to live before you see them as available variables. The Changes to the Admin tool configuration on on Beta currently and once testing is complete will be pushed to live. So the work is done but testing needs to be complete and these sit under slightly different release cycles but both will be available shortly. As an FYI we will also shortly be releasing some enhancements to the Activities options which include a calendar view as well as the ability to view other users, groups activities in lists, boards or calendars based on rights etc which may well also be of benefit if the team will be using the activities views. Thanks Steve
  25. Hi Kelvin The development story to allow 'mapping' from the progressive capture questions to specific request fields (Summary / Description etc) is in our incoming queue but has not been started yet. This is a high priority change and we will post back once this is available. Could you just confirm if it is actually the ability to update the Request Summary and other Request fields with the answers from your PC custom questions you are looking for? and or if you were looking to inject the answers from PC custom questions or request variables into say BPM Task or Authorisation description fields? As Neil alludes to above, we are working on a solution to allow this, and there is some documentation on our wiki which refers to how you could achieve the injecting of request variables into tasks / authorisations nodes currently, ahead of the more menu driven approach which Neil and the team are working on? https://wiki.hornbill.com/index.php/Request_Variables Thanks Steve
×
×
  • Create New...