Write the handoff down once. Let it run every time.

Start workflows when a deal is moved to won, a proposal is accepted, a task changes status, a form is submitted or a Stripe invoice payment arrives. You can also use schedules and webhooks. Deal won fires when someone edits a deal to the Won stage, not when a signature or project conversion moves it. Project completion and manually marking an invoice paid do not currently trigger automations.

An event still needs context. A form submission might represent a new lead, a change request, or an internal request, each with a different appropriate response. Use conditions and the documented event fields to distinguish the cases you intend to handle. Do not let one broad workflow turn every incoming event into the same operational commitment.

Supported action types include creating a project or task, changing a task status, sending an email, creating a notification or invoice, assigning a team member, updating a deal stage, creating a channel, and making a webhook call. Conditions and delays provide structure between the initial event and those outcomes. Templates can offer a starting point, but their assumptions still need review.

Use a test case to check recipients, amounts, payload fields, and failure behavior before enabling email, invoice, or webhook actions. Once the result is right, your team has a repeatable follow-up with a record of each run.

Imagine a published intake form for client design requests. A submission triggers a workflow that checks the request type, creates a review task, and notifies the responsible account owner. The task contains the relevant submitted context. The account owner then checks scope and capacity before assigning production work.

This illustrative workflow deliberately separates receiving the request from accepting it. A requested date should not automatically become a promised deadline. Start by testing a complete submission, an incomplete or unusual submission, and a case that should not match the condition. Inspect both the run record and the resulting task to confirm that the workflow did what the team expected.

Complexity is easiest to control before a workflow starts producing live records. A small automation with an obvious result is easier to verify and maintain than a large graph whose purpose is unclear.

1. Describe the manual process

   Write down the event, the decision, the action, and the exception path. Confirm that the team agrees before building the graph.

2. Map the supported fields

   Use the actual event schema and field paths. Check value types and required fields rather than guessing from a label in the interface.

3. Test representative cases

   Run a successful case and important edge cases. Inspect created records, recipients, and logs, not just the fact that a run started.

4. Assign an operational owner

   Name the person who will review failures and update the workflow when the business process changes. Keep a manual fallback for important handoffs.

A workflow cannot infer whether a scope change is fair, whether a prospect is qualified, or whether an invoice should be disputed. Conditions can represent agreed rules, but the rules must exist first. Keep an explicit human review where the decision depends on ambiguous commercial context.

Use webhooks to send data to another service's endpoint. Configure the payload and authentication that service requires, and test the response before using the connection in a live workflow. These connections are configured by your team; Flowboard does not provide a native connector marketplace.