Caching

A script, a flow, an individual flow step, or an app’s inline script can each be told to cache its result for a set number of seconds. While the cache is warm, running that same runnable again with the same input skips the computation entirely and returns the stored result instead.

This is most valuable for steps that are slow or expensive to recompute — a call to a rate-limited API, an aggregation over a large table, anything where re-running with identical input just burns time and quota for the same answer.

Cache flows

Caching a flow means its result — for a given set of flow inputs — is reused for the configured duration instead of being recomputed on the next matching trigger.

To enable it:

1. Settings: from the Flow editor, open the “Settings” menu and select the Cache tab.
2. Enable caching: toggle on “Cache the results for each possible inputs” and set the duration, in seconds.

With a duration of 60 seconds, for example, a flow re-triggered with the same inputs within that window returns the cached result immediately instead of running again.

Cache flow steps

The same idea applies at the step level: a single step’s result, for a given set of step inputs, is cached for the configured duration.

To enable it:

1. Select a step: in the Flow editor, click the step you want to cache.
2. Enable caching: open the Advanced menu, go to Cache, toggle it on, and set the duration in seconds.

With a duration of 86400 seconds (one day), a step re-triggered with the same input within that day returns its cached result instead of re-executing.

Conclusion

Caching cuts out repeated work in a flow whenever the same inputs are going to produce the same outputs anyway.

Caution

Cache duration should match how often the underlying data actually changes. A step whose output depends on something that changes more often than the cache duration will serve stale results until the cache expires — and caching things that shouldn’t be reused at all just adds needless memory overhead for no benefit.