Jump to content

SLA Rules using Organisation/Organisation Industry not applied on Import Requests

Recommended Posts

We recently undertook an import of request form an ZenDesk service desk into Hornbill which all loaded correctly in to Hornbill, except for the active requests where the incorrect Service Level Agreements where assigned as the SLM Rules to determine the correct SLA to apply did not evaluate correctly.

New request logged correctly since the migration directly in Hornbill do have the correct SLA applied using the rules in place.

Our SLA rules use both the Organisation and Organisation Industry to determine which SLA to apply and as per best practice we have a default catch all rule to apply a default SLA. All the imported active requests got the default SLA. It appears the Organisation relationship used by the SLA rules is not being set properly by the import tool, so it is not able to evaluate the Organisation name or Organisation Industry values used in the rules.

In terms of the imported requests these where matched at the user level by h_logon_id and also supplied the h_container_id of the organisation, using v1.8.1 of the tool.

We have two concerns,

  • One how to do we avoid this for future migrations, so that SLA rules apply properly?
  • We have had previous issues in our instance where requests have subsequently become cross linked to the incorrect organisation due to different interpretations of the organisation and container id relationships, which has involved @Victor have to undertake corrections.

Example SLA rule below





Link to comment
Share on other sites

Hi @Martyn Houghton,

The SLA Rules are worked through before the call is logged - effectively in the Service Manager interface - not after a call is logged (as part of the BP).

The Request Importer script(s) do/es not use the interface, logging calls directly in Hornbill. It consequently does NOT know anything about any SLA rules.

If you want to implement the SLA logic, then you will need to apply that logic in the request data source.

Please note that the request importer scripts are made as one-off imports to get data into Hornbill - with a one-off effort at script configuration time. The script was not expected to be oft-used or replicate any interface logic (i.e. like Progressive Capture; if you want to map data, you need to manually map it).

Link to comment
Share on other sites


Not to question this but with Service Level Management my understanding the assessment of the SLA Rules occurs when the work calls the Start Response and Resolution Timer nodes after the call has been logged by the workflow process. The Start Resolution time nodes exists in the workflow route of the BPM used for the imported active requests.

The fact that the active requests got the default SLA specified by the rules and not our actual default SLA tends to suggest the rules are in play here.

Also the requests we transferred over with the on-hold status did not have an SLA assigned to them until the suspend awaiting the request to come off hold and then reached the Start Resolution Timer nodes in the workflow, thereby indicating that the SLA was not applied at import.




Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...