Sometimes it might be useful to add loops to the workflow, or otherwise make steps repeatable.
For example, when trying to download many pages of data from an endpoint, I might want to run a request that downloads 1000 items, then repeats the step again until all items have been exhausted.
The only workarounds today are to re-trigger the webhook or to implement an adaptor function which does what I want (this is fine for pagination but doesn’t scale well to other problems)
I was just wondering if there has been any other suggested workaround to this 
Hi @ericchingalo ! Can you tell me more about your use-case? Then I can give you a better answer.
We don’t have any immediate plans to add support for this to the runtime itself.
If you’re using a webhook, one approach is to make the whole workflow repeatable. So you fetch a page of data, process it, and at the end of the workflow, if there’s more data to fetch, you trigger your own webhook again to process another batch of data. You’ll have to track some pagination metadata on your state object for this to work - but it’s doable.
We’re adding automating pagination to more and more adaptor APIs at the lately. But they just let you pull bigger pages of data - they don’t give you the facility to process pages of data individually.
Thanks @joe , sorry for the late reply.
Well my use case was migration of data from Google sheets to DHIS2, specifically into event Programs in the DHIS2 data model. The data were found in different files corresponding to different event programs in DHIS2. Since I wanted the workflow to be re-usable to all data files (DHIS2 event programs), I had configurations stored in DHIS2 data store where, where each data store keys had an object value defining the data source (Google Sheet ID), corresponding DHIS2 program and program stage, and the data column mappings with other DHIS2 metadata.
From this set up I had initially though of the first step being fetching the DHIS2 datastore configuration’s and for each of these configurations go through with the steps of getting raw data from google sheets, mapping the data into DHIS2 event payloads, paginate the mapped events data and import the data using DHIS2 tracker API.
In this case my thought was to have looped steps for each configuration on the steps for data transformation and uploading but also another loop on the steps after pagination to allow for paginated data importation into DHIS2.
But as @joe had suggested I just ended up having two hacks to this challenge.
each function to post the chunked event data into the data uploading workflow.That kinda sorted the challenges. But it would be interesting if at all we could have looping steps within a workflow.
Hey thanks for getting back to me!
So you’re pulling a bunch of DHIS2 events, and for each of those event, you’re pulling data from a sheet on Google Sheets?
And you could do this in a single workflow… just get all your events in one step, and then for each event pull data down from google sheets.
But that leaves you with a worse audit trail - like it’s harder to see what’s going on in the app - and maybe the workflow is pulling a massive amount of a data, taking ages to run, and it gets a bit risky if it fails for some reason.
But what you really want to do is pull your events data, and for each event, pause the loop and call out to a different step (or maybe a bunch of steps) to process them. And when all that’s done go back to the first looping control step and onto the next event.
I think the approach of having two workflows, once called from the other, works well for now. You’ll get to see a rich history of each Event being processed in the app. And actually if one goes wrong, it’s quite easy to just retry that one event - which is quite nice because things DO go wrong!
Actually I was taking some legacy survey data from google sheets and save them into DHIS2 event program.
But yah sure, I had figured out that splitting it into two workflows makes more sense and becomes easy to maintain.
Thanks @joe