Do you think twice when you get an automatic SMS notification because your prescription is ready? (Neither do I.) This seamless experience is driven by “workflow automation”, a key feature that OpenFn provides. The OpenFn Integration Toolkit is a Digital Public Good (DPG) used by governments and NGOs to boost efficiency through workflow automation. The automation that OpenFn provides includes automatically sending SMSs, automating stock updates across supply chain systems, tracking clinical visits, and helping plan vaccine rollouts. We support our partners’ work by lifting the burden of manual data transfers between platforms.

OpenFn automation happens via jobs which define specific steps ("operations") that OpenFn should perform. They're written in a scripting language that runs on top of (and has full access to) Javascript. A basic understanding of Javascript will take your job writing on OpenFn to the next level. To improve my limited knowledge of JavaScript, I have been taking Codecademy's Introduction to JavaScript Course.

Have you ever struggled to layout the strategy for testing your React App? Well, you are not alone! Here a few hints from the lessons I learned during my experience testing a React/Redux app with a Phoenix/Elixir backend.

We're very happy users of Elixir and Phoenix at OpenFn, given that we've been using it continuously for about 6 years - upgrades and all. Our front-end toolchain, albeit far from out of date (Webpack 5.52.1 today) has left some room for improvement.

So you're using docker's multi-stage builds and noticed that your build times aren't nearly as quick as you expected?

Jobs are business processes turned into functional-style scripts. What does that mean, how should you approach writing jobs?

This is a quick one, but I just got off an exciting call with an organization that's going to set up some jobs to move data into Salesforce from CommCare and realized that despite this being one of our more common integration requirements, we haven't done a 'tips' article for this type of project. Until now.

“Syncing” is getting two systems to a state of harmony. This might mean keeping a list of patients up to date, though modifications can be made in either system. It might mean copying transactions from one system to another on a nightly basis. It might mean a lot of things, but the key concept is that when you sync systems, you’re asking them to work together while simultaneously respecting both software systems’ independence.

In this post we’ll discuss two different syncing protocols to consider when designing your data integration. These include:

1. Real-time, or event-based, syncs
2. Scheduled syncs

Zandile is a program manager at an iNGO and she needs to use CommCare, DHIS2, and OpenFn for an upcoming public health project. She understands that all three pieces of software can be deployed locally, or accessed as SaaS (Software as a Service).

Essentially, Zandile needs to decide if she would like to run the software on someone else’s servers (SaaS), or on her organization’s own servers (deployed locally). Before making a decision she outlines the basic, non-technical considerations for both options.

tl;dr: Lots of our users want to upsert tracked entity instances in dhis2, but upserts aren’t supported by a standard DHIS2 API endpoint. We built one in our dhis2 adaptor: it’s composed of existing APIs and a bit of logic 🤔. Now you can upsert tracked entity instances to DHIS2 👍 ✅.