Flows: what happens after a document gets signed

Getting a document signed is only half the job. In most businesses, a signed contract or engagement letter needs to go somewhere afterward: into an accounting system, onto a case file, over to a colleague who's waiting for it. Before Flows, that "somewhere" was a person. Someone had to remember to download the signed PDF, rename it, and drop it in the right place, every single time. Miss it once and a client's signed contract sits in an inbox instead of the system where it's supposed to live.

Flows is Signedy's answer: a small, modular workflow engine that runs automatically the moment a document finishes signing, and does whatever follow-up work a business defines once, ahead of time.

Event-driven, not polled

The engine advances on a single event: delivery.completed, fired the instant every signer on a delivery has signed. Signedy already runs an outbox pattern internally for reliable event delivery (write the event in the same transaction as the state change, then process it asynchronously), so hooking Flows into that hook was a natural fit rather than a new subsystem bolted on the side. There's no polling loop checking "is this done yet?" The pipeline simply wakes up when the real-world event it cares about actually happens.

A Flow itself is a linear list of steps. Each step is one of a small, fixed set of types:

• SFTP upload: push the signed document to a folder on a remote server, the way many accounting and case-management systems still expect files to arrive.
• Webhook call: POST a payload to a URL, for businesses that already have their own systems and just want to be notified.
• Email step: send the finished document to an address that isn't one of the original signers, e.g. a bookkeeper who needs a copy of every signed engagement letter.

Steps run in order, one delivery's Flow at a time. If a step fails, that's recorded against the delivery rather than silently swallowed, which matters more than it sounds: an SFTP server rejecting a connection should look different from "everything worked," to anyone auditing a specific delivery later.

The part that had to be built carefully: credentials

Both the SFTP and webhook step types need something a plain workflow config file shouldn't hold in plaintext: real credentials. An SFTP step needs a password (or a private key). A webhook step often needs a bearer token or a shared secret so the receiving side can trust the request actually came from Signedy.

Those secrets are encrypted at rest with AES-GCM through a dedicated SecretProtector, keyed off an EncryptionKey environment variable rather than anything baked into the application code. That separation matters for a document-signing product specifically: Signedy already handles legally significant documents under GDPR, and the same discipline that applies to document content has to apply to the credentials Flows stores on a business's behalf, not a looser standard just because it's "only integration config."

Why a fixed set of step types, not a general scripting engine

It would have been possible to build Flows as something closer to a general automation platform: arbitrary scripts, conditional branches, a dozen step types. We deliberately didn't. A form-first e-signature platform's customers are accountants, law firms, and HR teams, not developers. A short, fixed list of step types that cover the overwhelmingly common cases (get the file somewhere, tell another system, email someone) is something a non-technical account admin can configure correctly, versus a flexible engine that's powerful but easy to misconfigure.

That constraint also shaped where Flows sits relative to Signedy's other recent work on multi-document envelopes: when a delivery can now bundle several documents signed together as one legal transaction, a Flow triggered by that delivery's completion naturally hands off the whole envelope, not a single file, keeping the "one signed thing, one set of follow-up actions" model intact as the product grows.