A few months ago, we began the implementation of the first phase of a submission notification trigger mechanism. This new functionality allows third party applications of your choice to be notified when a response to a survey is received – allowing the data to be immediately processed by your application.

Until recently, the trigger mechanism only supported notifications of newly received submissions, however, we have now implemented the ability to notify your custom application(s) when a submission is edited in your research console as well – thereby maintaining data integrity between our systems and yours.

In both cases we have also improved the processing mechanism in terms of dealing with failed delivery. The submission trigger mechanism will now reprocess a trigger in the event of a delivery failure (such as network failure or your server being offline). This ultimately means you are always ensured of receiving a notification of a submission even if your processing application is down while a submission is received. The new processing mechanism will make up to 6 attempts to notify your application as per the following schedule (assuming failure of the first and subsequent requests):

  • Retry 1 minute after first failure
  • Retry 5 minutes after second failure
  • Retry 20 minutes after third failure
  • Retry 1 hour after fourth failure
  • Retry 4 hours after fifth failure

If the result of the 6th attempt is a failure, we will notify you via email and wait on a resolution before re-processing the undelivered notification(s).

A successful notification delivery is defined as an attempt that results in a “200 OK” HTTP status code being returned by the relevant web server. If any other code is returned our system will deem the delivery a failure and enter the reprocessing workflow as described above. Furthermore, if a “500 Internal Server Error” code is returned we will record the error message returned and supply this information to you in the event the notification is not delivered after 6 successive attempts.

In terms of the requirements for setting up a create/update notification trigger, we simply require the URL endpoint of your service and the survey ID you wish to setup the trigger(s) for. Once setup, the notification to your URL endpoint is simply made via a GET request with the following query string parameters.

On submission created notification:

KEY

Type

VALUE

surveyid

Integer

ID of the survey the submission received is relevant to.

submissionid

Guid

The unique ID of the submission record.

createdon

DateTime

The date and time the submission was received.

createdby

String

The name of the fieldworker who captured the submission.

On submission modified notification:

KEY

Type

VALUE

surveyid

Integer

ID of the survey the submission updated is relevant to.

submissionid

Guid

The unique ID of the submission record.

modifiedon

DateTime

The date and time the submission was modified.

modifiedby

String

The name of the user who modified the submission.

If you have any comments, questions or suggestions, please feel free to post them here, alternatively, please contact support.

We hope you find these new features useful.