Microsoft Flow, HTTP Action, and 302

by erikyadams

I have a pet cat that is getting old. We recently were informed that this cat is diabetic, which means she will have to eat specially formulated food and get insulin shots. That’s all fine – the food can be purchased online, and the vet we use can get us needles and insulin when we run out. But I immediately had a problem: what do I do with the used needles? The vet didn’t know. She knew that they could collect and process them for an outrageous fee, but she didn’t know how the frugal pet parent could take care of things themselves. I had to figure it out on my own. (The answer, by the way, is you can buy needle disposal boxes at drug stores, and then ship them to a company that will dispose of them properly.)

Which gets me to Microsoft Flow. Time has marched on, and I need to automate a fairly simple task. Oh, sure, in another life I could bang out a Python script or a C# application to do this, but for various reasons that have nothing to do with technology, I’m using Microsoft Flow. Unfortunately, the lack of documentation and “crowd sourced” developer support mean I feel right at home.

I am attempting to make a Flow that retrieves a file via the HTTP action, but I encounter a problem: when a GET request is made to my specified URL, the server doesn’t return the file; it returns a HTTP 302 redirect. The princess is in another castle. According to Wikipedia, HTTP 302 means “Found” – not missing, not moved, but found, and will include a new URL in the response headers. It is a redirect, and not an error, at least according to the current HTTP specification.

But Microsoft Flow calls it an error, and if a flow encounters a redirect it stops. This is the wrong behavior, and a problem because I really do need to download a file. I’m not the only person to encounter this issue, but the forum posts that claim to solve the problem don’t actually help. I think this is because everyone gave up on Microsoft Flow and moved on to other products where a 302 redirect was handled correctly, like Zapier or Integromat. But I’m stuck with Flow for now, and need to make it work.

My solution is to manually get the “Location” header returned in the initial response, and then make a second HTTP request. It appears that everyone who makes a post about Microsoft Flow has to include a screen shot of what their flow looks like, so here’s mine:

flow

(This screen shot was make in July of 2019. If you are in the far future, your Flow might look completely different. Sorry about that.)

The first action triggers the rest of the flow once per day. The first HTTP is configured to do a GET request for a URL. It’s in the next step where things get a little clever. I define a variable called “RedirectURL”, type String, and use this expression to get the value I need:

actions('HTTP').outputs.headers.Location

The variable action is also configured to run after the previous action has failed. (Again, a redirect is not an error, but whatever.) The second HTTP request makes a GET request to whatever URL is stored in RedirectURL, which gets the file I want to process.

Overall, I’m not very impressed with Flow. The documentation stinks. It seems that this is a product that evolved very quickly over the last few years, and the documentation has not kept up. I often found documents on Microsoft’s web site that would explain how to do one thing or another that had screen shots of “actions” that don’t exist any more, or have been renamed, or updated so significantly the documentation is worthless. The product itself seems to have been renamed multiple times, which only adds to the confusion. The interface for actions has changed significantly, but the documentation hasn’t kept up. That’s bad enough but the fact that Microsoft doesn’t then have people on hand to provide support makes the situation worse. Add to all that, I genuinely think no one is using this product.

Wit developer products, like .Net, it is reasonable to keep out of date documentation, because someone will have to maintain a legacy product. But for something like Flow, where we are all using the same platform, keeping out of date documentation around is just bad form. As I write this Microsoft just announced that they are making boatloads of cash; perhaps they can use some of that to hire some writers and fix these issues.

As I’ve been working on this problem, I’ve been comparing Flow to other automators, and things look even worse. When I needed help with Zapier or Integromat, I found web forms that sent email to actual employees, as opposed to links to discussion forums. The employees got back to me within 24 hours, which isn’t very fast but is pretty reasonable when you’re dealing with companies that are 9 time zones away. I also like the interfaces of the competition better, but I concede that is a personal preference. Really, I think the only thing Flow has going for it is that it is owned by Microsoft, and no one ever got fired for buying Microsoft.