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.
Currently, the integration has only been tested against version 10 of Uniform.
Limitations
- Only
General
,Noise
, andPest
Service Requests are supported at present, although other types (i.e.Contract
,Dog
,Food
,Non-EH
) are planned for future development. - 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.
- 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
.
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.
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.
After giving your mapping template a name, you must select the type. There are 3 types of mapping template that can be created:
- Submit General Service Request (outgoing) - defines the fields to be populated when creating a General Service Request.
- Update General Service Request (outgoing) - defines the fields to be updated when updating a General Service Request.
- General Service Request (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.
Finally you must complete the mappings.
In the first row of the mappings you must select which Reference
the template applies to. For Submit General Service Request
templates, this means that the reference number for the new Service Request will be stored in this Reference. For Update General Service Request
templates, this means that the reference number of the Service Request to be updated, is held in this Reference. For General Service Request
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.
You should not rely on the integration to ensure that data is removed from the Jadu Connect case or the Uniform Service Request automatically when clearing down personal data in either system. The specific tools provided in each system should be used directly to ensure that no personal data is left unnecessarily.
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 General Service Request mapping template being applied. All incoming mapping templates for the applicable Reference will be applied.
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.
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 integration has failed due to a validation error (e.g. due to an invalid mapping value), it will not be retried.