Trigger second form

Is it possible to automatically trigger or open a next form in a flow directly after submitting the previous form, without requiring the user to click on the next form/task explicitly?

1 Like

No, I do not think that this is supported by the CHT. I have moved this thread to the #product group, though, as this is an interesting feature request! It would be great if you could share more details about the workflow challenges you are trying to address (and particularly how the the current tasks functionality does not meet your needs).

As a technical note, I do not think it would be very difficult to include this functionality in the CHT. The hard part would be to determine how to configure which new forms to trigger when a report is submitted…

2 Likes

Just wanted to also include some additional context from the broader ODK ecosystm. That thread raises some additional questions/features that should be considered (e.g. passing data to the new forms). Though, it is worth noting that the feedback from the ODK team on the thread was basically to propose using a single large form instead of triggering multiple smaller forms in sequence…

Thank you for your answer. We are currently trying to find a solution for a parallel flow which only gets triggered depending on a form output variable. In order for a smoother process, we thought it would be optimal if we could then trigger and open the first form of the parallel flow automatically when the criteria is met.

1 Like

I have been experimenting with the “instance::db-doc” column to generate pull other form from a form.

initially I though this would start the subform in the form filler (enketo) but it seams it only create a fake submission, the docs seems to confirm Creating Additional Docs from App Forms | Community Health Toolkit) ?

I read here that there is no solution but I think I won’t be the only one needing it

Here some use cases:

  • immunization have some complex skip logic, other questionnaire will benefit of starting it without copy/pasting the questions
  • complex questionnaire (we are reaching 2000 lines on the xlsx) are slow, they will would benefit of being sliced up
  • sometime a questionnaire follows directly another questionnaire but other time a task will be created for the second questionnaire to be done later in case like out of stock or time consuming activity required etc (duplication of the questions make it difficult to maintain)

regarding the question “e.g. passing data to the new forms”

I think having an “inputs” group on the same level as the “instance::db-doc” could fake the task approach

Similar post: