Skip to main content

Idox - Uniform

The Idox Uniform integration allows Service Requests to be raised in Uniform using data from Jadu Connect cases. At the point that a Service Request is created or updated, information from the Service Request can also be pulled back and stored in fields on the associated Jadu Connect case.

The Idox Uniform integration requires Jadu Hub Integration Server (HUBis). Please contact us for more information.

  • The following Service Requests are supported at present:
    • General
    • Pest
    • Noise
    • Dog
    • Non-EH
    • Food
    • Reception
note

Currently, the integration has only been tested against version 10 of Uniform.

Limitations

  • Currently only one-way integration is possible; updates made to the Service Request directly in Uniform would not be pushed back to Jadu Connect.
  • Service Requests can be created or updated, but cannot be closed or have their status updated.

General settings

On the General tab you can enable / disable the integration with Uniform, and configure its settings.

When you save the settings, with the integration enabled, Jadu Connect will attempt to connect to Uniform in order to verify the settings.

If the connection fails, the settings will not be saved, and an error message detailing the reason for the failed connection will be displayed.

General settings

  • Reference Type code (SRREFTYPE) - this code is used when raising Service Requests, to identify the originating system (i.e Jadu Connect).
  • Timezone - the timezone set for Uniform in "Location/Area" format (list of supported timezones). Defaults to Europe/London.
  • Connection timeout - the number of seconds to await a response from the Uniform server. Defaults to 30.

Valid values for these settings will have been configured when the integration was initially set up in HUBis so they may not need to be changed when enabling the integration.

References

A Reference is a special type of field used to store a Service Request reference number against a case. When creating a mapping template, the reference which the template applies to must be selected.

References

Service Request reference displayed on case details

Mapping templates

A Mapping template is a set of mappings which define the data to be passed between Jadu Connect and Uniform when creating and updating Service Requests.

Mapping Templates

Mapping Template

After giving your mapping template a name, you must select the type. Any of the following mapping templates can be created:

Submit (Outgoing)

Defines the fields to be populated when creating a Service Request.

  • Submit Dog Service Request
  • Submit Food Service Request
  • Submit General Service Request
  • Submit Noise Service Request
  • Submit Non-EH Service Request
  • Submit Pest Service Request
  • Submit Service Request Reception

Update (Outgoing)

Defines the fields to be updated when updating a Service Request.

  • Update Dog Service Request
  • Update Food Service Request
  • Update General Service Request
  • Update Noise Service Request
  • Update Non-EH Service Request
  • Update Pest Service Request
  • Update Service Request Reception

Incoming

Defines the Service Request data which should be pulled back from Uniform and stored on the Jadu Connect case, following a create/update action instigated by Jadu Connect.

  • Dog Service Request
  • Food Service Request
  • General Service Request
  • Noise Service Request
  • Non-EH Service Request
  • Pest Service Request
  • Service Request Reception

Mapping Template

Finally you must complete the mappings.

In the first row of the mappings you must select which Reference the template applies to. For Submit Service Request templates, this means that the reference number for the new Service Request will be stored in this Reference. For Update Service Request templates, this means that the reference number of the Service Request to be updated, is held in this Reference. For incoming templates, this means that the template would be applied following a create/update action linked to this Reference.

The subsequent rows are field mappings. In order to raise a General Service Request in Uniform, at a minimum the Complaint Type code for the Service Request must be set. You can then add as many additional mappings as you wish by clicking the Add Another button.

The following type of data can be used from the Jadu Connect case:

  • Case field values
  • Case dates
  • Linked Person details
  • Linked Address details

You can also configure a manual text mapping, if the value of the Service Request field should be the same each time that mapping template is used.

Mapping Template

Outgoing mapping templates are applied via rules, using the Apply integration action.

Incoming mapping templates are applied as a result of a Submit or Update Service Request mapping template being applied. All incoming mapping templates for the applicable Reference will be applied.

Apply integration rule action

note

Since integrations are run as background tasks and will be retried in the case of any connectivity failure, it is likely that any subsequent rule actions (e.g. sending an email) will be performed before the Service Request has been created / updated in Uniform. This should therefore be accounted for when designing workflows.

Adding a new customer to an existing Service Request

For a lookup to occur, at least one of the following fields must be mapped:

  • Service Request matching Postcode
  • Service Request matching Property name or number
  • Service Request matching Street name

If any of these required fields are mapped, Connect will then attempt to find an existing record in Uniform that also matches any of the following optional fields, if mapped:

  • Service Request matching excluded statuses
  • Service Request matching included statuses
  • Service Request matching Property type

If none of the required fields are mapped, the lookup will not occur.

This functionality is available on all Submit mapping templates, except for the Non-EH mapping template.

These values work as conjunctive filters, meaning that an existing Service Request must have values which match all mapped fields.

For instance, if the Service Request matching Postcode field is mapped with the value E20 6PQ, and the Service Request matching Property type is mapped with the value FLAT, Connect will attempt to find any Service Request that has those Postcode and Property type values. If any Service Requests have a matching Property type, but a different Postcode, this will not be considered a match.

If a single existing Service Request has been found in Uniform, the customer details mapped for this integration action will be added as a new customer to that Service Request.

If multiple Service Requests, or no Service Requests are found matching the criteria, a new Service Request will be created instead.

There is no functionality to check if any customer details already exist as a customer against the matching Service Request. A new customer will always be added to the matching Service Request, regardless of which customer details may already exist against that Service Request.

Log

The integration log provides a summary of case integration actions that have occurred; including where service requests have been successfully created or updated, and where service requests have failed to be created (including the reason for the failure, if known). The log also details any validation failures when creating or updating the Service Request, or when updating the case with values from the Service Request. Reviewing the integration log can help to identify incorrect mappings, or areas where validation during data capture are insufficient.

Where an action has failed due to a connection issue or other intermittent error, it will be retried up to a maximum of fifteen times. If the integration has failed due to a validation error (e.g. due to an invalid mapping value), it will not be retried.

Log