Idox - Uniform Building Control
The Idox Uniform Building Control integration allows Building Applications to be raised in Uniform using data from Jadu Connect cases. At the point that a Building Application is created, information from the Application 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
- The following Building Application types are supported:
- Building Notice
- Full Plans
- Regularisation
- Currently only one-way integration is possible; updates made to the Building Application directly in Uniform would not be pushed back to Jadu Connect.
- Building Applications can be created, but cannot be updated.
General settings
On the General
tab you can enable / disable the integration with the Uniform Building Control Connector, 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.
- 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 Building Application 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 Building Applications.
After giving your mapping template a name, you must select the type. Any of the following mapping templates can be created:
Outgoing
Defines the fields to be populated when creating a Building Application.
- Submit Building Notice Application
- Submit Full Plans Application
- Submit Regularisation Application
Incoming
Defines the Building Application data which should be pulled back from Uniform and stored on the Jadu Connect case, following a create action instigated by Jadu Connect.
- Building Notice Application
- Full Plans Application
- Regularisation Application
Finally you must complete the mappings.
In the first row of the mappings you must select which Reference
the template applies to. For Submit
Building Application templates, this means that the reference number for the new Building Application will be stored in this Reference. For incoming templates, this means that the template would be applied following a create action linked to this Reference.
The subsequent rows are field mappings. You can add as many 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 Building Application field should be the same each time that mapping template is used.
Outgoing mapping templates are applied via rules, using the Apply integration
action.
Incoming mapping templates are applied as a result of a Submit Building Application 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 Building Application has been created 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 Building Applications have been successfully created, and where Building Applications have failed to be created (including the reason for the failure, if known). The log also details any validation failures when creating the Building Application, or when updating the case with values from the Building Application. 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.