2
1 Comment

Falcon Builder Enterprise Healthcare Client

We got our first enterprise client on Falcon Builder a couple of months ago, bringing our ARR to $18K in pure licensing fees. As we've built out this platform, it has become instrumental for this client, which now has over 600 workflows in production!

posted toAvatar for product Falcon Builder
Falcon Builder
  1. 1
    600+ production workflows for one enterprise client is where this gets really interesting. At that scale, I've been thinking less about whether an agent/workflow can execute correctly and more about what independently establishes that a consequential action was still authorised at the moment it actually affected another system. Take a workflow that updates a record, sends a customer communication or triggers an external action. It can have valid access, pass its checks, execute the expected path and produce a clean audit trail. But if authority changes between the earlier approval/decision and the downstream consequence, there are really three separate questions: Was it technically permitted? Was it still authorised when the consequence occurred? Can the downstream evidence establish what actually happened? We've been exploring that separation with OpsWatch, particularly because “the workflow says it was blocked” and “we can prove the external consequence did not occur” aren't necessarily the same state. With 600+ workflows now running for the healthcare client, have you encountered cases where Falcon's internal execution evidence wasn't enough by itself and you needed to reconcile against the downstream system to establish the real outcome?