CommCare

CommCare HQ is Dimagi's mobile data collection platform for frontline field programs that work offline. Agents read and write cases, pull form submissions and attachments, manage mobile workers, locations and lookup tables, and react in real time when a form is submitted or a case changes.

Verified 4 triggers 73 actions API key available

CommCare website Platform Documentation Capability data verified 2026-08-26

On Case Created fires when a field worker's device syncs a newly registered household

Agent reads the case properties the worker recorded in the field

Get Case By External ID looks for the beneficiary in the registry that owns the identifier

Upsert Case By External ID writes or refreshes the record so a repeated sync cannot duplicate it

Update Case writes the resolved facility and enrollment status back onto the case

The program manager receives the day's registrations grouped by location

The program manager resolves the registrations that matched more than one existing beneficiary

What This Integration Enables

CommCare is built for programs whose data is collected by people standing in front of other people, often with no signal. That single fact shapes everything about how it should be automated. A case in CommCare is not a row, it is a longitudinal record of a household, a patient, or a stock point, owned by a named worker and carried on a device that may be offline for hours. Changes propagate on sync, not on save, and the person you would want to ask about a bad write is the one you cannot reach.

FlowRunner agents read and write that world through the whole public surface: cases through the JSON case API with upsert on external ID so a repeated run cannot duplicate a beneficiary, form submissions and their attachments, applications and their multimedia, mobile workers and web users, the location hierarchy, lookup tables, custom report data, messaging history, and device logs. Four triggers ride CommCare's own data forwarding engine and fire when a form is submitted or a case changes. These connectors are built and verified against the vendor's official API, including behaviors that produce a silent wrong answer rather than an error: CommCare answers a rejected form submission with a success status and reports the real outcome in the body, and its list valued user fields replace rather than merge.

Field programs are exactly where human-in-the-loop stops being a nice principle and starts being the only responsible design, because the blast radius of a bad write reaches handsets nobody can recall.

Without FlowRunner

Field data waits for a report cycle What a worker records today reaches the registry when someone runs an export, not when it is collected

Reference lists go stale on devices A price list or drug register updated at head office arrives on handsets whenever someone remembers to publish it

Failed reminders are invisible An SMS that never reached a caregiver looks identical to one that did until someone audits the log

With FlowRunner

Registrations flow on sync A case created offline reaches the downstream registry the moment the device reconnects

Reference data has an owner upstream Lookup tables are maintained from the authoritative system, and devices receive the current list on their next sync

Delivery failures get named Messaging events are read on a schedule, and the recipients whose reminders failed reach a person with the reason

Use Case Scenarios

Registrations reach the registry as they sync

A community health worker registers a household on a device that has been offline all morning. When it reconnects, On Case Created fires and the agent receives the case with every property the worker recorded. It calls Get Case By External ID against the national beneficiary identifier, upserts the record so a repeat sync cannot create a second one, resolves the facility against the roster in Google Sheets, and writes the resolved facility back with Update Case so the worker sees it on their next sync. Nothing waited for a monthly export, and the registry and the device agree.
Reminders that failed reach a person, with the reason

On a schedule, the agent calls List Messaging Events filtered to errors for the previous day. Each event carries the recipient and the individual messages nested inside, so a failed SMS survey shows which exchange broke rather than just that something did. The agent groups the failures by cause and by location and posts them to the program manager in Slack, with the caregivers whose reminders never landed named individually. A follow-up call list exists the same morning instead of surfacing in a quarterly review.
Staff onboarding and offboarding as one run

A new field officer starts. The agent reads the record from BambooHR, calls Create Mobile Worker with the short username CommCare expects, and assigns groups and the primary location in the same run. Because the account confirmation flow is used, the worker sets their own password rather than receiving one from an automation. When someone leaves, the agent reads the current record first, reassigns the cases they owned, and only then deactivates or removes the account, because a worker removed while still owning cases leaves those cases without an owner.

Human-in-Loop Highlight

Bulk Upload Lookup Tables is the operation on this connector with the widest blast radius, and it is disguised as a routine sync. Lookup tables are the drug registers, price lists, and facility rosters that field applications read, and CommCare requires a replace flag on every upload request. With replace on, the upload deletes the project's existing lookup tables before it loads the workbook. Applications that reference a table by tag stop finding it, and the consequence lands on handsets during the next sync, in places where nobody can push a correction back. FlowRunner only ever puts the two literal values on the wire, because CommCare's server treats any other value as truthy and replaces.

So a lookup table sync from an upstream system of record stops before the destructive path. The agent reads the authoritative list, diffs it against List Lookup Table Rows, and posts what it found: "The price list in the source system has 214 rows. The project's Prices table has 209. The diff is 7 new rows, 2 changed prices, and 2 rows present in CommCare but not upstream. I can apply this with Update Lookup Table Row and Create Lookup Table Row, which touches only those 11 rows. The alternative you asked about, a workbook upload with Replace Existing Tables on, first deletes all 4 lookup tables in this project, including Facilities and Cadres, which this workbook does not contain. Apply the row level diff, or replace?" The program lead answers. In practice the answer is the row level diff, which is the point: the agent made the safe path visible and the destructive one explicit. The reconciliation was automatic. The choice that would have reached every device in the field belonged to a person.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

73 actions

Cases

List Cases Lists cases in the project with cursor pagination, which is what keeps it usable on very large caseloads. Follow the next link unmodified. Filtering on an unset property is a real filter rather than an omitted one.
Get Case Reads one case with its properties and metadata. The lookup step before any decision that depends on the current state of a beneficiary record.
Get Case By External ID Reads a case by the identifier the upstream system owns rather than by CommCare's own. Note that CommCare does not enforce uniqueness on external IDs, so this returns one match when several share an identifier.
Get Cases In Bulk Reads many cases in one call. Used to gather a working set before a reconciliation or reporting pass without paging the whole caseload.
Create Case Creates a new case. It always creates, so supplying an external ID that already exists produces a second case rather than updating the first. Use it only when a workflow knows the record is genuinely new.
Update Case Updates a case's properties. Every property value is sent as a string because CommCare rejects other scalars, and property names must be valid XML element names.
Upsert Case By External ID Creates or updates a case matched on its external identifier. The default write for any sync workflow, because a repeated run refreshes the record instead of duplicating a beneficiary.
Bulk Create Or Update Cases Writes up to a hundred cases in one request, applied through a single generated form submission. Entries can reference one another by temporary id, so a parent household and its members are created together.
Close Case Closes a case, which takes it out of the active caseload that syncs to devices. Used when a beneficiary graduates, transfers, or exits a program, and worth confirming before it runs, because the worker who sees it disappear is usually offline.
Get Case With Related Forms Reads a case together with the form submissions behind it. The only route that can return the forms that produced a case, which makes it the audit step when a value looks wrong.
Download Case Attachment Pulls a file attached to a case, such as a field photograph, into FlowRunner storage and returns a URL later steps can use.

Case Import

Bulk Upload Cases From Spreadsheet Uploads a spreadsheet of cases for import. A success response means the file was accepted, not that every row landed, which is why the status action exists.
Get Case Import Status Polls an import until it finishes and returns created and matched counts alongside the row level errors. Business problems such as an unknown owner name are reported here and nowhere else.

Forms

List Form Submissions Lists form submissions, excluding archived ones by default. For incremental pulls, order and filter on the indexed date, which handles forms arriving late from a device that was offline.
Get Form Submission Reads one form submission with its answers, case transactions, and device metadata.
Download Form Attachment Downloads a file attached to a submission. The raw submission XML is itself an attachment, so this is also how a workflow retrieves the original record.
Submit Form Posts raw form XML through CommCare's submission endpoint. CommCare answers a rejected submission with a success status and reports the real outcome in the body, so this action reads the body and raises rather than reporting a discarded form as accepted.

Applications

List Applications Lists the applications in the project space. The first step when selecting a form definition, because forms are addressed within an application.
Get Application Reads one application's definition, including the forms it contains and their namespaces.
Import Application Imports an application into the project space. Used when a program standardizes a tool across country projects.
Upload Application Multimedia Uploads media used by an application, such as the audio and images a low literacy form relies on.
Get Multimedia Upload Status Polls a multimedia upload until it completes, so a provisioning workflow knows the application is ready before it tells anyone.

Mobile Workers

List Mobile Workers Lists the mobile workers in the project space with their groups and locations.
Get Mobile Worker Reads one mobile worker. Always the first step before an update, because the list valued fields on the update replace rather than merge.
Create Mobile Worker Creates a field worker account, taking the short username without the project suffix that CommCare appends. Leaving the password empty with account confirmation on lets the worker set their own credentials rather than receiving one from a workflow.
Update Mobile Worker Updates a mobile worker. Groups, locations, phone numbers, and custom user data replace rather than merge, so read the current record, edit the returned list, and send it back.
Delete Mobile Worker Permanently removes a mobile worker, which is not the same as archiving. Cases the worker owned are not deleted but lose their owner, so reassign ownership before this runs.
Send Mobile Worker Password Reset Sends a password reset to a mobile worker, which is the supported path when someone is locked out in the field.

Web Users

List Web Users Lists the web users with access to the project space and the roles they hold.
Get Web User Reads one web user's record and role.
Invite Web User Creates an invitation rather than an account. The person is not a project member until they accept, and the role is given by name exactly as it appears in the project's role list.
Update Web User Updates a web user's record. As with mobile workers, list valued fields replace rather than merge.
Activate Web User Reactivates a web user's access to the project space.
Deactivate Web User Suspends a web user's access without removing the record. The reversible option when someone goes on leave or an access review is pending.

Account

Get My Identity Returns the identity behind the connection. The cheapest confirmation that region, username, and key line up, because it needs no project permissions.
List Project Spaces Lists the project spaces the credential can reach, which is how a workflow resolves the project slug from the display name.
Search Users In Bulk Looks up many users in one call. Used to resolve owners and assignees before a bulk write rather than one at a time.
Validate User Credentials Checks a set of credentials against the project. Used in access review workflows.

Groups

List Groups Lists the project's groups, including which ones share a caseload.
Get Group Reads one group with its members and settings.
Create Group Creates a group. Case sharing on a group means every member can see and edit the same caseload, which has real consequences for who can read personal data, so it stays off unless a shared caseload is intended.
Create Groups In Bulk Creates several groups in one call, used when a program stands up a new district or cohort structure.
Update Group Updates a group. The member list and the metadata object replace rather than merge, so read before you write.
Delete Group Removes a group. Deleting a case sharing group leaves the cases it owned without an owner, exactly as removing a worker does.

Locations

List Locations Lists the project's location hierarchy. The name filter is case sensitive.
Get Location Reads one location with its type, parent, and site code.
Create Location Creates a location. Names must be unique among siblings and site codes unique across the project, and the parent must accept children of the given type.
Update Location Updates a location, applied atomically so a partial write cannot leave the hierarchy inconsistent.
Bulk Create Or Update Locations Writes many locations in one call, atomically. If validation fails for one entry, none are written, which is the behavior you want when restructuring a hierarchy.
List Location Types Lists the location types configured for the project, which define what can be a child of what.
Get Location Type Reads one location type, used to validate a hierarchy change before attempting it.

Lookup Tables

List Lookup Tables Lists the project's lookup tables. These are the reference lists field applications read, so this is the inventory step before any sync.
Create Lookup Table Creates a lookup table with its column definition.
Update Lookup Table Updates a lookup table. Changing the field definition replaces the column set, and removing a field removes that column and its stored values from every row.
Delete Lookup Table Removes a lookup table and every row in it. Applications referencing the table by tag stop finding it, and they find out on the next sync.
List Lookup Table Rows Returns rows in the nested format CommCare requires for writes, which supports several translated variants per column. The read half of a safe row level sync.
Create Lookup Table Row Adds one row to a lookup table. The additive half of a row level diff.
Update Lookup Table Row Updates one row in place. Together with the create and delete row actions, this is the non-destructive way to keep a reference list current.
Delete Lookup Table Row Removes one row from a lookup table.
Bulk Upload Lookup Tables Uploads a workbook of lookup tables. With the replace flag on, this deletes the project's existing lookup tables before loading, which is why this page's human gate exists. FlowRunner sends only the two literal flag values, because CommCare's server treats any other value as truthy and replaces.
Get Lookup Table Upload Status Polls a lookup table upload until it finishes and reports what actually landed.
List Fixture Items Returns lookup table rows as a flat field map, which is usually the easier shape for a workflow to read and compare.
Get Fixture Item Reads one lookup table row in the flat format.

Reports

List Reports Lists the project's custom reports along with the filter slugs and column identifiers the download action takes.
Get Report Configuration Reads one report's configuration, so a workflow knows what it is about to download and how the columns are typed.
Download Report Data Downloads report rows, which is how a program dashboard gets aggregated indicators without extracting raw case data. Several values for one filter are joined the way CommCare expects rather than with a comma, which would match nothing.
List Report Data Sources Lists the underlying data sources behind the project's custom reports.
Get Report Data Source Reads one data source's definition.
Get Report Data Source Rows Reads rows from a data source directly. This route sits behind a CommCare feature flag the vendor must enable for the project.
List Data Export Tool Configurations Lists the project's export configurations, used to align an automated pull with the exports analysts already trust.

Messaging

List Messaging Events Lists SMS and email events, one per recipient per source, with the individual messages nested inside. The audit route that answers whether reminders actually reached people.
Get Messaging Event Reads one messaging event with its nested messages and their outcomes.

Device Logs

List Device Logs Reads the diagnostic logs CommCare mobile clients send back. The route that explains a field problem when the worker reporting it is not reachable.

Triggers

4 triggers

Event Triggers

On Form Submitted Fires when a mobile worker submits the selected form, delivering the complete submission with every answer, the case transactions it performed, and the device metadata. Select an application and then one of its forms. CommCare registers a data forwarder when the trigger is enabled and removes it again when it is disabled.
On Case Created Fires when a case of the selected type is created, delivering the new case with its metadata and every property. Used to push a newly registered patient, household, or stock item into another system the moment a field worker records it.
On Case Updated Fires when an existing case of the selected type changes, delivering the case as it stands after the update. Creations do not fire this trigger.
On Case Created Or Updated Fires on every change to a case of the selected type, covering creations and updates in one subscription. Used when a workflow keeps an external record in step and does not need to tell the two apart.

Frequently Asked Questions

What can FlowRunner do with CommCare?

FlowRunner agents can run List Cases, Get Case, and Get Case By External ID in CommCare, plus 70 more actions.

Does connecting CommCare to FlowRunner require OAuth?

No. CommCare connects to FlowRunner with an API key, no OAuth flow required.

Can CommCare trigger a FlowRunner workflow automatically?

Yes. CommCare supports 4 triggers that can start a FlowRunner workflow automatically.

Start building with CommCare

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us