We use Make for orchestration that needs to remain visible to both development and operations. A typical scenario might start with a Custom Webhook, pass through Routers and Filters, and then call external services through HTTP modules. This setup makes it easy to adjust a branch when a business rule changes, without having to ship another version of our API. Error Handlers are where the platform became much more reliable for us. We use Retry, Resume, Skip, Commit, and Rollback depending on the type of failure, and Incomplete Executions give us a way to recover after fixing the underlying issue instead of treating every run as disposable. We really noticed the difference during a synchronization when a provider started returning intermittent rate limits. Our earlier scenarios would simply stop and leave us guessing which records had actually made it through, but adding a retry path made the flow far more predictable. Data Stores have also been useful for keeping small pieces of state, supporting idempotency, and maintaining references between executions. Review collected by and hosted on G2.com.

What I still miss are stronger diff and review tools between scenario versions. As scenarios grow, it becomes harder to track what changed and why. To keep things manageable, we try to keep flows small and move more complex logic into .NET when automation shifts from orchestration toward core application code. Make is great for connecting systems, but business rules shouldn’t quietly evolve inside visual workflows that aren’t being properly reviewed. Review collected by and hosted on G2.com.