In the ODK Collect v1.16 Beta - #20 by LN thread, @Fabla brought up that it would be useful not just to add SMS as a way to send forms but also to send messages from the form to do things like thank participants.
I believed this was already possible using the external app feature but it turns out that's not true. While that feature allows us to launch different applications and to pass special values called Android extras to them, the android.intent.action.SENDTO message requires knowing who to send the messages to and that's not done through extras.
I think this would be very useful to add. See this sample form for how I imagine it being used (doesn't work in Collect today).
The narrowest way I can think of supporting this in Collect is to introduce a special key in the parameter list that allows the form designer to specify a recipient(s). I would like to propose uri_data as its name since that is unlikely to already be part of forms and because it matches what it will represent from an Android perspective (see data in https://developer.android.com/reference/android/content/Intent).
A similar use case would be useful for email. It would be great to be able to send the completed form to the subject at the point of completion, so that they have a record of what they just filled in.
Hi @LN, great work done, i just have a test of the form and i was thinking the message in the calculation field ("Thank you, ", ${name}, "! We can't wait to see you on the study start date.") is the one which will be send to the person's number, when you enter the number and click on lunch it will link you to the phone's sms tab with that phone number and the message box will be empty, i was thinking when you click on lunch it will auto send Thank you Helene! We can't wait to see you when the study start. to the person's phone number.
Thanks for trying it out @Fabla, your feedback is always appreciated!
I totally understand the desire to send directly from Collect. The challenge is handling error cases, providing meaningful feedback to the user and enabling re-submission. As @yanokwa said, it can quickly get complicated. Using the default text messaging or email app ensures that all of those details are correctly taken care of. All that to say I agree with gathering a bit more feedback and seeing if there’s high demand or more ideas on the approach.
Just to add to this thread a use case for email capability, though perhaps at Aggregate end and not on devices.
I have a form (let's say it is a form to request a new account) on ODK aggregate. This form might only be filled very occasionally, either by ODK Collect or more likely on Enketo - feeding in to an Aggregate back end.
I don't want to have to look every day to see if anyone has submitted any new requests, so would like to get an email saying "You've got a new submission to form x"
For legal purposes I want to also send a confirmation to the person filling the form in which says "Thanks for filling in this form" and optionally "here's a copy of what you just said in the form".
In practical terms this might mean that XLSForm needs two new variable types in settings sheet i.e. notify.owner which takes an email address and some text to form the body and subject of message to owner of form. also notify.respondent which does the same but for the person filling in the form.
Neither behaviour specifically needs ODK Collect to do the heavy lifting on the email side as the server can do that part, which presumably is easier to set up.
Why not just use Zappier to send a new email when a database record is added? You can send to afixed email (say yours) and a variable (say the form completer's email that you capture in the form).
This would save any development need and is user configurable, if you have access to the database.
FYI, in our (admittedly) non-Collect deployment, we have the need to do something very similar; in our case sending what is called a "site notice" to predetermined recipient(s) at the conclusion of an inspection, eg emailing the restaurant owner after conducting a food premises inspection. Initially this we did in the backend by having the webservice constructing a form summary report - basically constructing a generic PDF version containing the question text with raw submitted form data - and emailing it.
However, because of the limited ability of the backend to parse, interpret and correctly render the XForm data (eg the backend doesn't have all the fancy XPath support to evaluate relevant expressions to know what questions to include include/omit in the report, insert result fields into note labels, etc), we've instead moved to a mobile device generated PDF form copy. We already have all the necessary tools in the ODK Collect mobile app (or in my case, iXForms app) so you can probably do a much better job in rendering a user-friendly printable version of the submitted form data. Also, it is immediately available on the device out in the field, so the enumerator/inspector can potentially email it right there and then, rather than saying "its in the mail...".
Alternatively, if you do want to do this in the backend, eg from Aggregate or Central, then I might suggest exploiting something like Enketo which has some XForm smarts to render the form+data into perhaps a HTML page, which that can then be saved to PDF for subsequent email.
Just thought I'd share some feedback from someone who's already had to tackle something along these lines with with XForms out in the field. Its actually turned out our so-called 'site notices' are hugely important to our consumers (or in turn their end-users), in some regards more so than the raw data (!). So good looking, readable, well-formatted PDF copies of form results are a big deal for us.
Its actually turned out our so-called 'site notices' are hugely important to our consumers (or in turn their end-users), in some regards more so than the raw data (!). So good looking, readable, well-formatted PDF copies of form results are a big deal for us.