7 Architectural Lessons From Building With the Tooling API

Publisher preview

Consider the following scenario: You try to delete an unused field on Account, but it is referenced in an obsolete flow version from eighteen months ago that nobody remembers building. You open the flow, scroll its version history, and start deactivating and removing flow versions one at a time. In an org with hundreds of flows and thousands of accumulated flow versions, this stops being a task and becomes a tax you pay on every cleanup, refactor, and deployment. To help clear that type of backlog at scale, I built and open-sourced a Flow Version Cleaner, a tool that uses the Tooling API to prune obsolete flow versions safely. What I expected to be a weekend project became a sequence of lessons about how the Tooling API behaves beyond the happy path, where everything works as expected. This post covers those lessons, which include identifying assumptions that break at run time, tackling dependencies and unexpected requirements, maintaining reliable state across asynchronous executions, and designing destructive operations to fail safely. The Flow Version Cleaner follows three key requirements:

A saved ApplyDjinn digest is not available for this story yet.

This preview is supplied by the publisher. The complete publication remains at its original source.