Comparing On-device vs Server-based SMS in CommCare

Owned by Marissa Harrison
Last updated: Apr 25, 2024 by Gillian Javetski
2 min read

Broadly speaking, CommCare supports two ways of sending out SMS messages:

  • Sending an SMS directly via a CommCare form on a mobile device

  • Configuring SMS to be sent from CommCareHQ’s servers via an SMS Gateway

See more details on each of these implementation strategies below.

Pros and Cons (when to use each method)

Sending SMS directly from a CommCare form is good for messages that are:

  • Real-time

  • Triggered during an app workflow

  • Time-sensitive -- especially in areas with inconsistent mobile data

  • Have no privacy concerns associated with sharing a mobile user’s phone number

Using CommCare Messaging is best for:

  • Asynchronous alerts or reminders

  • Batch messages sent out to many users at once

  • Messages that need to be sent from an anonymous or system user

  • Automated, interactive SMS workflows

Sending an SMS directly via a CommCare form on a mobile device

See documentation Sending an SMS directly from a CommCare form on how to implement this in CommCare form builder.

  • Level of effort (app-building): ~1 hour to configure your first message, several minutes for each subsequent message

  • User Experience: User taps on a button that says “Send SMS” inside a CommCare form. They are taken to the SMS interface of their device, where the list of recipients and message content has been pre-populated from hidden variables in CommCare. When the user taps “Send”, they are automatically returned to CommCare.

  • Requirements: Mobile SMS credit on the user’s phone

  • Caveats: Can be hard to verify if an SMS message was actually sent or not. Can’t send messages asynchronously. Messages originate directly from the mobile worker’s phone

Configuring SMS to be sent from CommCareHQ’s servers via an SMS Gateway

See extensive linked documentation CommCare Messaging on how to implement this functionality using the CommCare messaging feature and an SMS Gateway provider.

  • Level of effort (app-building): EXTENSIVE. Requires dev work to set up SMS Gateway compatibility internally, as well as partner-facing negotiations to set up the SMS Gateway externally. Interface is fairly user-friendly, but requires several hours of exposure before app-builders fully grasp all the details.

  • User Experience: Messages are delivered asynchronously. The messages typically originate from a “short code” assigned by the Telcom involved, and may be configured to accept user responses. The messages can be triggered by:

  •  

    • A specific date

    • Change in a user case property

    • A manual broadcast

  • Requirements: Activation of SMS Messaging Feature Flags (“Outgoing Messaging” and “Incoming Messaging”), Custom Dev Work to configure SMS Gateway internally, selection of SMS Gateway provider that operates within the country you’re working in, Implementation work to configure SMS Gateway externally

  • Caveats: Time-consuming and expensive to set up. Dimagi adds a surcharge of $0.01 per message sent. Users must sync data with the server in order to trigger SMS messages.