How Strkr's no-code flow builder actually works

Most CRM vendors call their automation feature a “workflow builder.” Open the actual product and you often find a 3-step form: pick a trigger, pick an action, save. That is not an automation platform. It is a form that fires one webhook. Teams outgrow it in a week.

Strkr’s no-code flow builder is built around what sales ops leads actually need: multi-step logic, cross-module data, scheduled runs, retry handling, and visibility into what happened and why. This post walks through what the builder does, how a flow is structured, and the kinds of workflows teams build with it in the first month on the platform.

The anatomy of a flow

A flow in Strkr has three parts: a trigger, a branch tree, and one or more actions at each leaf of the tree.

• Triggers are the thing that starts the flow. Record change (a deal moved to Closed Won), scheduled run (every Monday at 7am), inbound webhook (a form submission), or manual fire (a user clicks a button).
• Branches are AND/OR condition nodes that split the flow into paths. A single trigger can fan out into any number of branches based on field values, record age, user role, or related-record state.
• Actions are what the flow does at each leaf. Create a record, update a field, assign an owner, send an email, post to Slack, call a webhook, trigger a second flow.

A simple flow has one trigger, zero branches, one action. A complex flow has one trigger, five levels of branching, and twenty leaf actions. The builder scales to both without a different UI for each.

What triggers can watch

Strkr’s triggers cover the four things teams actually want to react to:

1. Record events. Any object (deals, contacts, accounts, projects, custom objects) can fire on create, update, delete, or specific field change. “When deal.stage changes to Closed Won” is one trigger. “When contact.email_opt_in flips to true” is another.
2. Scheduled runs. Cron-style schedules in natural language. “Every weekday at 9am,” “First Monday of each month,” “Every 15 minutes.” The flow fires with no record context and acts on whatever query you define inside it.
3. Inbound webhooks. Every flow gets a unique inbound URL. Point a form, a payment processor, or an external system at it and the flow fires on receipt.
4. Manual fires. Any flow can be exposed as a button on a record page. The user clicks it, the flow runs with that record as context. Useful for “Convert lead to opportunity” or “Create project from deal” buttons where the user wants explicit control over when it happens.

Branching: AND, OR, and real logic

The branch node is where Strkr diverges from most CRM “workflow” tools. A branch takes a condition expression and splits the flow into a “matched” path and an “unmatched” path. Conditions can combine with AND, OR, and NOT, and they can reference the triggering record, related records up to three levels deep, the current user, or constants.

Concrete example: a deal moves to Closed Won. One flow handles the whole post-sale cascade. The branch tree looks like this:

• Trigger: deal.stage changed to Closed Won
• Branch 1: deal.amount > $50,000 AND deal.account.industry = “Healthcare”
  • Create a project from the enterprise-healthcare project template
  • Assign to the healthcare delivery pod
  • Post to #healthcare-wins in Slack
• Branch 2: deal.amount > $50,000 AND deal.account.industry != “Healthcare”
  • Create a project from the enterprise project template
  • Assign to the default delivery pod
  • Post to #sales-wins
• Branch 3 (fallback): everything else
  • Create a project from the standard template
  • Assign round-robin to the delivery team

One flow, three paths, zero conditional complexity in the actions themselves. The branches hold the logic.

Actions: what a flow can do

Strkr’s action library covers the full workspace, not just the CRM module. A single flow can touch records across CRM, Marketing, Projects, Docs, Surveys, and Messaging because they all share the same data model.

Common actions, grouped by use case:

Record operations:

• Create a record in any object (standard or custom)
• Update one or many fields on the triggering record or a related record
• Delete a record (soft-delete by default)
• Clone a record with field overrides

Communication:

• Send a transactional email through Strkr’s email layer
• Post a message to Slack, Teams, or Discord
• Send an SMS through Strkr Messaging
• Create an in-app notification for a specific user

External:

• Call a webhook with configurable payload and auth
• Query an HTTP endpoint and store the response as a flow variable
• Enqueue a long-running job that reports back on completion

Flow control:

• Wait a specific duration (useful for drip sequences or delayed follow-ups)
• Trigger another flow with context
• Loop over a collection of records
• Store a value in a flow variable for use by downstream actions

The practical outcome: a flow is a program, not a trigger-and-forget macro. Teams write real sequences, not single-step reactions.

Formula fields inside a flow

Flow actions can set field values using the same formula engine that powers formula fields. That means the action does not need a hardcoded value. A “set deal.priority” action can use a formula like IF(deal.amount > 100000, "high", IF(deal.amount > 25000, "medium", "low")) to compute priority from the deal size.

Formula functions in flows include the full set: IF, CASE, AND, OR, CONCAT, DATEDIFF, FIND, MID, SUBSTITUTE, ROUND, FLOOR, CEIL, MOD, YEAR, MONTH, DAY, HOUR, WEEKDAY, and the full math library. Anything a formula field can compute, a flow action can set.

Observability: what happened and why

A flow builder without run history is a liability. Strkr’s run history shows every execution of a flow, which branch it took, which actions fired, and the final state. If an action failed, the error is right there. If a flow fired but did nothing because every branch’s condition was false, the history shows which branches evaluated and why.

Teams use the run history for two things: debugging flows that aren’t firing as expected, and auditing what the automation touched. “Why did this deal get assigned to Sarah?” is a question the run history answers in two clicks.

The flows teams build in month 1

Here are workflows new Strkr customers typically have running within their first 30 days:

1. Deal closed → project created. the handoff workflow from the examples above. One of the first flows every services team builds.
2. Lead captured → assigned → notified. inbound form fires the flow, lead is scored, assigned to the right rep by territory + capacity, Slack notification fires.
3. Deal gone cold → re-engagement task. scheduled flow runs daily, finds deals with no activity in 14 days, creates a task for the owner with context from the last activity.
4. Contract renewed → NPS survey. deal.renewal_date passes, flow waits 30 days post-renewal, fires an NPS survey through the Surveys module, posts response to the account record.
5. High-value deal moved to Qualified → exec notification + custom pipeline. branches on deal amount, high-value deals get copied to a parallel exec pipeline for leadership visibility while continuing through the standard pipeline.
6. Project milestone slipped → renewal risk flag. Projects module milestone marked late, flow finds the related account’s next renewal opportunity, flips a risk field, notifies the CSM.
7. New account from Stripe → full onboarding sequence. Stripe webhook fires the flow, account is created with billing data, welcome email sends, onboarding project kicks off, calendar booking link goes out to the primary contact.

None of those required a developer. All of them run on the same builder.

When a flow is the wrong tool

Flows are not the right answer for every automation question. A flow runs on event, not continuously. If you need something to recompute every time a related record changes, that is a formula field, not a flow. If you need to transform data at query time, that is a formula report, not a flow. If you need bidirectional sync with an external system, that is an integration, not a flow.

The rule of thumb: if the automation is “when X happens, do Y,” it is a flow. If the automation is “the value of Y should always reflect X,” it is a formula.

Where to go from here

The flow builder is included on every Strkr paid tier at no gated-feature upcharge. The 14-day free trial gives you full access to build and run real flows against real data. If you want to see the broader platform first, the product overview covers how flows connect to the rest of Strkr, and features breaks down each module in depth.

Related reading: the Projects module overview covers the deal-to-project handoff flows are built for, and the forecasting feature page walks through the weekly rep cadence that flows plug into.