No-groups, duplicators and reading fine print

Feb. 25, 2016

By Elliot McBride, Innovation Lead at UNICEF Pakistan Innovation Lead.

While I’m definitely not claiming to be the most expert of RapidPro users, below are the biggest solutions to common problems that I have had whilst designing flows.

1. Add all beneficiaries to ‘No’ groups first

Let’s say you want to get all of the registration information about a beneficiary, but you don’t have the space to do it as whilst getting the necessary feedback the flow has been designed for. In this case water availability and quality.

Considering flows should really only be 4 or 5 SMS’ long, gaining the information you need about your contacts may not be collected all at once. Creating groups that show what information users are missing  i.e. ‘no district’ and adding all users to all of these groups will allow you too gradually gain this information about users later and gradually remove them from these groups. See below.


This way, if you don’t have the space to ask for the beneficiaries’ district, gender or name, you can revisit these particular traits later with either campaign targeting that specific ‘no’ group (before removing them from it as seen above). Alternatively you can collect this information about users by adding one or two registration questions onto the flows you are using for your program.

A short registration flow for a water project, could look like:

  • Please enter your district (remove user from ‘no district’ group)(update user @flow.district)
  • Was there water at the tap when you came to collect it today?
  • Was it clear?
  • Did it have a bad smell/taste?

Your follow up flow could then be:

  • What is your age? (remove user from ‘no age’ group) (update user @flow.age)
  • What is your gender? (remove user from ‘no gender group) (update user @flow.gender)
  • How far do you have to walk to gain access to a working tap? A) <1km, B) 1-2km, etc.

2. Flow design to ignore duplicate entries.

If your flows are receiving multiple runs from the same user you can omit them by opening a flow with a split by groups function. Begin the flow by first splitting the users by group membership. Create a new group for all users that have finished your flow. Once they have finished – add them to this ‘exclusion group’. Therefore, if they trigger the flow again their membership to the exclusion group will split them to a thankyou message. If they are not, they get to do the flow – and then they are added to the group that will exclude them if they trigger the flow again.


Make sure you split by the name you give your flow group:


3. Read the onboard simulator reference text

If you ever want to save, update or repeat information based on what is given by the user as an answer – look at the onboard simulator. The fine print gives a step by step of the logic that RP uses and then shows you how this translates to a text message. To refer to previous answers, you just need to copy in the reference handles that RP creates (e.g. @flow.age).  The example below shows what references you need to use to repeat the information typical to that user.


Here we can see that the onboard simulator gives us the answer - if we want to reference previously given responses the answers are given to us in the fine print. Boom.

I’m sure that there are a number of ways to achieve these tasks. Even better if people have alternative thoughts/methods that they think are more effective. Please email me at

Keep chasing that rainbow.