Wait until File Changed HTTP+Webhook

On March 16, 2018 at 07:13:15 UTC, I tweeted the core idea behind this trick: if Flow does not have a second trigger, then we can build our own waiting primitive with HTTP+Webhook.

It sounds like a small trick until you need it. Then it becomes one of those ideas that changes how you think about the platform.

This is me tidying up notes from the old archives.

The main insight was simple:

• a parent Flow can start a long-running wait
• a child Flow can watch for the condition we care about
• when the condition flips, the child Flow calls the callback URL
• the parent resumes as if the platform had supported the wait natively

Why this mattered

At the time, Flow was strong at event-driven automation, but weaker at expressing “wait until something changes” as a first-class primitive. In traditional SharePoint workflows, this kind of “wait until changed” pattern was already very familiar, so the mental model carried over naturally. The important detail is that this is a webhook-based async wait pattern, not a polling trigger. The child flow waits for the callback, then resumes the parent when the event arrives.

HTTP+Webhook gave us a way to do the wait without polling the platform.

The result was not just a workaround. It was a pattern:

• create a generic child watcher
• pass in the thing to observe
• wait, poll, or monitor in the child
• call back when the change is detected

That meant we could reuse the same shape for more than one kind of long-running business process.

The original walkthrough

The long-form walkthrough for this idea is here:

• Design a “Delay until SharePoint File Changed” HTTP+Webhook for MicrosoftFlow

The flow pattern

The parent Flow is the easy part: it just hands off control to the child watcher.

The child Flow does the real work:

1. Capture the callback URL from the parent.
2. Look up the current file metadata.
3. Store the modified time.
4. Loop until the file changes.
5. Call the callback URL once the change is detected.

That turns a trigger-shaped problem into a composable waiting service.

Images from the original post

Related reading

• Working with SharePoint WebHooks with JavaScript using an Azure Function
• One Flow to handle them all - Part 2 figuring out the changes
• Community response from @ISSPDEV
• The original Flow-jutsu entry for this hack

Tweetstorms are easy to miss later, so it helps to turn the useful ones into something people can find again.

What I would say now

If I were rewriting this today, I would say the same thing more plainly:

• Flow needs a reusable wait primitive
• HTTP+Webhook can act like that primitive
• SharePoint file changes are just one example
• the broader lesson is that waiting is a workflow shape, not just a trigger

What matters is not just the workaround itself, but the way it trains you to think about Flow as something you can compose from smaller pieces.