Work Order Connector
Field users are redirected to the full work order page.
The Work Order Connector has been designed to redirect users at the work order level in the Deepomatic application. With this connector, user flow follows the following steps:
Users open a work order (or equivalent) page in their field application.
By clicking on a button, they are redirected to the Deepomatic interface, on the corresponding work order page.
Users can then be guided in taking the expected photo, take the photo, view the analysis results and report any issue.
Once they are done, they finally return to the original field application to continue their journey.
The three sections below describe the technical steps and options to create this experience.
Creating work orders
In order to send users to a work order page in the Deepomatic application, a work order must have been created in our systems. To do so, you must choose between two possibilities, depending on what is most suitable for your IT architecture.
Work order creation via API
Work orders can be created in advance, for example during work order planning. To do this, it is necessary to use the endpoint for creating a work order, which is described here.
The work order id will be used to redirect the users to the right work order page in Deepomatic. This id is returned in the work order creation API response and should therefore be saved.
Work order creation on the fly
It is also possible to both create a work order and redirect the user at the same time using a unique URL:
Query parameters can be provided to specify information at the creation:
work_order_name (string) - name of the work order. If not specified, a value will be set by default.
wo_metadata (base64) - metadata of the work order. Metadata let you store custom data on a per work order basis.
type_names (string) - types of the work order. Work order types allow you to filter the tasks of a work order. They first need to be defined at the application level by the Deepomatic team.
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
state (base64) - parameter that allows you to pass data through the different steps of the flow.
The work_order_id, work_item_id and input_id should be stored as they will be necessary for other redirections.
With the on the fly option, there is some limitation on the amount of information that can be passed through the URL. For maximum compatibility between browsers, keeping the length under 2048 characters is recommended.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
Sending the users to the Deepomatic interface
When the work order has already been created, the following URL should be used to send the user to the Deepomatic interface:
Optional query parameters are also available:
callback_URI (URI) - URI where the users will be redirected after leaving Deepomatic interface. If no URI is provided as a query parameter, then the users are redirected to their parent app via the default callback URI.
Two precisions on the callback URI :
Any query parameter included in the callback URI that bears the same name as a Deepomatic query parameter will be ignored to avoid conflicts in the callback redirection.
The callback URI sent through the query parameters should be encoded to avoid conflicts between special characters.
The fragment identifier # and the token have to be placed at the end of the URL. Every other information placed after the fragment identifier will not be read and sent to the server.
Retrieving data generated by Deepomatic
At the work order level, we compute a progress score based on the different analyses carried out.
On your field application, we recommend to put in place a logic for closing the intervention based on the work_order_progress (eg. if the progress is below a certain threshold, the users cannot close their intervention).
The work_order_progress (integer, between 0 and 100) is directly returned with the callback URL.
In order to retrieve the images and the complete analyses of a specific work order, you will need to use the endpoint to get a work order described here.
Last updated
