Jump to content

Martyn Houghton

Hornbill Users
  • Posts

    4,014
  • Joined

  • Last visited

  • Days Won

    86

Posts posted by Martyn Houghton

  1. @Cigdem Turner

    If you retire the catalogue items under the service, so new requests are not able to be logged, but not the service itself then the customers will still be able to access their current and closed requests under the service.

    We then use the service availability setting to set it as Impacted advising them the service is retired and pointing them in the direction of the new service (if there is one). Then eventually we will then retire the service as well.

    Cheers

    Martyn

    • Like 1
  2. @Adrian Simpkins
    We post them under "CRM & External Customer Service & Support" as there is no 'Customer Portal' topic.

    I am hoping the new Knowledge Base facilities will allow us to easily select documents on the request and the customer will be able to see and access the linked document directly from the customer portal.

    Hopefully, there will be an update on this at the March HUG meeting.

    Cheers

    Martyn

    • Like 1
  3. This is becoming quite a barrier for us, as trying to push our Account and Project Managers to use the Employee Portal to view customer (external contacts) requests where they are added as a connection.

    Due to the volume of requests where they will be a connection on, not having even a basic textual filter to allow the manager to filter by request request reference or external organisation name is a real barrier to making use of this functionality.

    Cheers

    Martyn

     

    image.thumb.png.7edaf1e0e95502ebd6690ac61d75e200.png

     

     

  4. Can we just check the current version of LDAP Utility show as 4.2.10 (patch) in the log file when run?

    Cheers

    Martyn

    2024/02/07 07:05:16 [MESSAGE] Flag - forcerun false
    2024/02/07 07:05:16 [WARN] Current version 4.2.10 (patch) is greater than or equal to the latest release version on Github 4.2.10

     

     

  5. @Estie

    Your calculation is based on 9 business hours a day, so I am presuming your Working Time Calendar is 08:00 to 17:00hrs (aka 9 hours).

    If you are working 5 days a week, then 6 months/182.5 days elapsed would be 130.35 working days (5/7ths), or if 7 days a week it would be the former 182.5 working days.

    As this is the SLA timer only counts when the Working Time Calendar is active, so 9  working hours times the number of working days 130.35 or 182.5 gives you 1,173.15 or 1,642.5 working hours.

    Now we can take the working hours and convert this into the units you need to enter into the SLA target.

    1,173.15 working hours equals 48 days, 21 hours, 10 mins.

    1,642.5 working hours equals 68 days, 10 hours, 30 mins.

    Cheers

    Martyn

     

     

     

     

  6. @AlexTumber

    Just checking the option to override visibility is applicable to both the 'Rasie new request' and the 'Update request' operations, as the screenshot appears to relate to a template used by the 'Raise new request' operation.

    The reason for having on 'Update request' is we are using email updates to bring in and trigger the BPM in relation to Enterprise Service Management actions happening outside of Hornbill.

    Cheers

    Martyn

  7. @Berto2002

    We were looking at using the email updates from JIRA to trigger the update being applied to the request and at the same time BPM checking the status of the linked JIRA using the existing iBridge methods.

    However, we cannot progress this approach as it is not currently possible to control the visibility of the email updates using the Auto Responder and we do not want internal development updates/comments appearing on the customer-viewable timeline.

    Cheers

    Martyn

     

     

    • Like 1
  8. @Berto2002

    +1 that we definitely need to make the customer and employee portals more interactive and give them outcome buttons which are dependent on the current stage/status. There can also be a 'reason' text field to capture their update, but in essence, we want the customer to categorise their response so the BPM can then act on it, rather than just coming off hold.

    There was a fix applied in relation to unpausing timers at the resolution stage which we are still testing at the moment.

    Cheers

    Martyn

    • Like 1
  9. @Gerry

    At the moment we use API's to create requests only. This requirement is to be able to retrieve an existing request and update it based on a change in an external system. Given the key to all the current 'end-user' api's is the request id, you would only know this if you logged the request via the api in the first place and then rettain this in the external system.

    Appreciate the need to optimise and engineer the request to be efficient both in resources and response time.

    From our current use case, we would be able to limit the search via Request Type and Service id(s) as mandatory criteria, plus the date logged/closed, status and sub-status as optional parameters. This is related to us wanting to import and keep in sync Change Requests for Projects being managed in Salesforce.

    Cheers

    Martyn

     

  10. @Luke

    As I understand it, the Default Time Categories is a flat non-structured configuration, so to set a default at the 'Request Type' level each Request Type has an entry to set this. I think this was from the very first initial implementation. Then with Service Manager development progressing the same configuration file added default settings at the 'Request Action' stages, which in essence take precedence over the higher level 'Request Type' ones.

    We have chosen to configure these down to the 'Request Action' stage and can confirm the defaults are picked up in Service Manager when Time Recording is enabled on the Request Type on Service Portfolio.

    Cheers

    Martyn

    image.png.898e3d5e2a6bc0921d88bae779e000c6.png

    image.thumb.png.f2a98abb087b15416bfd1c0788cc7c8f.png

    image.thumb.png.3e887858eb36bfa0309a1ab36ad4f40f.png

  11. Linked to our earlier request back in 2020, we would like to create and update Change Requests in Service Manager from an CSV extract from Sales Force. Our colleagues in the Project and Delivery teams use a product within Salesforce to monitor and track their projects. We would like to create, update and close these project as Change Requests in Hornbill so we have visibility of these within the Service Manager, to head off calls for use to use Salesforce or even discussions around potential toolset changes. As they use a third party module/product within Salesforce we do not able the ability to look at more complex integration.

    At the moment we can only create the Change Request via the Request Import Tool, but we can not update it. The idea is that when there are any changes between the CSV and the current values on the request in Hornbill, the request would be updated along with a timeline entry for audit purposes.

    This would only be for a few key fields such as

    • Summary
    • Description
    • External Reference
    • Schedule Start/End
    • Status
    • Plus some of the custom fields

    Cheers

    Martyn

     

     

×
×
  • Create New...