Jump to content

David Hall

Hornbill Developer
  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by David Hall

  1. Hi @samwoo

    Ok glad to hear we're making progress.

    Regarding the starting of the targets/timers, essentially the answer to your question is yes, wherever you place the start timer node in the BPM, it will be looking at the request data at that point in time and will apply your rules based on that, so if the priority is not set but you have referenced it in your rules then you will have the scenario where the SLA/SL is not applied.

    As an outsider to your organisation/processes its hard for me to say what the preferred course of action is in this case, but essentially you could do one of two things...

    1. Adjust BPMs as needed to ensure the start SLM nodes are placed after the relevant data has been captured against the request (this would normally be the most logical and straightforward option)

    2. You could create essentially a holding SL for requests where the priority is not set e.g. a "P - Unknown / 0" with default response/resolution times and set this with a new rule for when priority is not set.  With the service manager setting guest.app.view.ITSM.serviceDesk.slm.enableAutomatedSLChanges enabled, when the priority is changed or set on the request it will then automatically re-run the service level rules and it would then update it to use the appropriate SL for the priority 

    Hope that provides some further guidance... let me know if you have any further questions.



  2. Good Morning @samwoo

    Ok so I think I now understand what is happening. 

    Currently you have created global SLAs and within the SLAs you have created multiple SLs (P1,P2 etc) and you have created rules within the SLA to determine which SL to select which is all correct.

    However, when you go to a service and link the global SLAs... if you link multiple SLAs to a service (which I believe you have done for your different Orgs W,B etc) then you would need to create rules within that service to tell it which SLA to select, otherwise it won't know and will default to the first SLA in the list.  Once the SLA is determined it will then process the rules in the SLA to determine the SL.  

    If you want to avoid creating rules within each service to determine the SLA, then I think you would need to use a single Global SLA (e.g. not one for each Org  W,B etc) and then associate that one SLA to all of your services.  That global SLA will be chosen automatically without any rules and then within your global SLA you could create some additional SLs and rules for each Org needed e.g.


    Would become

    W - P1
    W - P2
    B - P1
    B - P2

    etc.  You can then adjust the rules in the global SLA to check if Org == W use W - P1 etc.


    Hope that makes sense, does that help to explain what you are currently seeing happening?

    Kind Regards,



  3. @samwoo

    Thanks for the detailed explanation.  

    So the process the app follows when determining the SLA and then the SL should go as follows:

    Based on the service set against the request...
    1. Get all SLAs associated to that service. 
    2. If only 1 SLA is returned then use it otherwise check for SLA Rules
    3. If no SLA rules found then use the first/top SLA that was returned
    4. If SLA rules found then process in order from top to bottom and return when a rule matches

    With an SLA Determined we then process for SL
    5. Get all SLs associated to the SLA
    6. If only 1 SL is returned then use it otherwise check for SL Rules
    3. If no SL rules found then use the first/top SL that was returned
    4. If SL rules found then process in order from top to bottom and return when a rule matches

    If I understand correctly, its the initial SLA selection that is incorrect, if it seems to be returning the first SLA in the list each time then perhaps you could try putting a different SLA to the top to determine if it is just defaulting to the first result.  If so then this would suggest no rules are set for the SLA selection (note there are two sets of rules, 1 for SLA and one for SL).  If this is not the case and it is still selecting the same SLA as before then it seems there is something incorrect with the rule criteria being checked in which case we can look further into that.

    If you have no joy there then we can schedule something to review the config and see if we can understand the root of the problem.

    Kind Regards,


  4. Hi @samwoo

    Company in this case refers to a company defined within the organisational groups configured in the admin tool to which Hornbill users can belong e.g.



    and within the entry you can assign users...


    So if annab was the customer on the request, the company criteria will check against the company she is assigned to (e.g. Dave H Inc in this example).

    Hope that answers your question but if not let me know.

    Kind Regards,


    • Thanks 1
  5. Hi @AndyHill

    Are you still experiencing this issue?  I've just done some tests on creating tasks with attachments, reopening and viewing the attachments and all appears to be working correctly at this time.  Please post back if you are still seeing issues.

    Kind Regards,


  6. All,

    This is an important message on how to ensure that your processes continue to run smoothly after 31/10/2021. The priority-based Service Levels (i.e. the configuration in the Service Levels tab shown below on the service portfolio view) will no longer be functional from this date, all service levels/targets will now need to be handled via the Service Level Agreements tab.  If you do not see the service levels tab or the red notice then there is no action to be taken.

    See more on this and on how to migrate here
    Hornbill How To: Transition to the new Service Level Agreement functionality - Hornbill



  7. Hi @Berto2002

    If you are using the standard selectors for selecting a service in the new request node etc then renaming the service should not be a problem, the logic will all be based on the underlying service id.  The only way in which you could see an issue if you have specifically referenced the name of a service in any custom expressions when branching etc.

    Kind regards,


  8. Hi @Berto2002

    Glad the issue has corrected itself after a cache clear. 

    Regarding the linking of corporate SLAs, typing into the field should provide you with a filtered list of corporate SLAs that you have configured within the service portfolio so it should filter and display results from the list shown under the Service Portfolio View -> "Service Level Agreements" tab.  Once you have an SLA selected the link button will be active.

    Kind regards,


  9. Hi @Kelvin

    Thanks for that update.. indeed something is not correct there. 

    So just to confirm those 2 incorrect entries that you have shown...  were they logged via self service portal or via the Employee portal?  Also just wanted to confirm whether the site in these cases is set via manual selection in the progressive capture or via a business process action?



  10. Hi @Berto2002

    I've just been trying to recreate.  Can you confirm whether you opened the links to the service or new service view via the Service Portfolio list or did you access the links directly? Also would just confirm that you have cleared cache etc in case there is an issue with the page loading following this morning's update.

    Kind Regards,


  11. Hi @Kelvin

    I'm not aware of any site specific changes in this latest update.  I've had a look and tested locally and I don't appear to be able to replicate this issue for existing or newly logged tickets which all display the site name for me.

    As a first step I'd just like to confirm you have done the usual basics with a log out/clear cache/log back in and then see if the issue persists.  After that perhaps confirm if any colleagues are seeing the same issue?  Let me know if the issue persists.

    Kind Regards,


  • Create New...