GlobiFlow Error Triage

After my musings on automating GF error recovery I have decided on a more manual approach. This provides more control and doesn’t add more strain on Podio when there’s an outage.

In this solution, I have an Error Triage app that captures errors and allows re-running of flows by clicking on a button.

Pretty cool actually.

The Errors App

I have an app in Podio called GF Errors with:

• Title (single-line text field)

• DateTime (calculation with created-on value)

• Error (single-line text field)

• Flow Name (single-line text field)

• Link to Item (location field)

• Link to Flow (location field)

• Command (category field with “Run Again” and “Ignore”)

• Text (multi-line text field)

In the email-to-app settings for the app, I have also made sure that the body of emails goes into the “Text” field:

In GlobiFlow, I have then set the error log to send errors to this new GF Error app’s email-to-app address:

New Error Flow

I then have a flow on creation of a new error to parse out some of the data and fill in the fields we’re interested in:

But, and very importantly, to prevent loops, this flow will only update the item if the error was generated by ANOTHER flow (ie not this flow who’s ID happens to be 1478494):

So now, when an error occurs, I have a nice representation in Podio:

It even has a link to the item in Podio as well as a link to the flow in GlobiFlow.

Run Again Automation

There’s also a flow on update to re-run a flow when the “Run Again” option is selected:

The first thing we need to do is extract the Flow ID and Podio Item ID from the text again, as well as set a “run” flag for later sanity:

Now, in order to use ProcFu to trigger this flow again, we need the app’s hook “c” and “p” values.

If you look at the hooks on any app that has GF flows, you’ll see them there:

For this particular app, c=1 and p=1267.

The c value is your GF customer ID. It will never change and is the same across all your apps, so you can use it directly.

The p value is GF’s internal ID for a given app in your account, so it will change from app to app.

For flexibility, I’m going to use ProcFu’s gf_get_p_value script to get the p value for the flow in question.

Before attempting to trigger the flow, let’s make sure we have all the required values - otherwise we’re just going to generate another error. In case we’re missing something, we’ll just add a comment and set the run flag to 0:

And finally, if the run flag is still 1 (ie we have all the required info), let’s trigger the flow again:

Conclusion

I believe this is the cleanest and most controllable approach to handling GF errors. There’s no risk of causing loops, and you have the opportunity to review the item in question before re-triggering the flow.