What is a low-code workflow builder and how is it different from a BPM tool or an iPaaS?
A low-code workflow builder is the visual canvas plus the execution engine that runs step-by-step automation sequences. A trigger fires (record change, time, inbound webhook, form submit, external event), the engine evaluates the matching flows, each flow executes its sequence of actions, and the flow completes. Workflow builders handle short-form automation that completes in seconds to minutes. A BPM (business process management) tool models longer-running processes with explicit states and approval chains that can run for days or weeks. An iPaaS specializes in moving data between systems. Strkr ships all three on one platform; a low-code workflow builder for short-form automation, business process management for long-running processes, and integration pipelines for system-to-system data flow; so the admin picks the right primitive for the shape of the problem rather than buying three separate tools.
What node types does the workflow builder ship, and does 180-plus cover real operational cases?
The 180-plus node count covers the real operational surface. Trigger nodes include record changes (create, update, delete, specific field change) on every CRM object, time triggers (cron, scheduled, delayed, recurring), inbound webhooks, email received, form submits, external events from native connectors (Stripe payment, DocuSign signed, Zoom ended), chat conversations, and manual triggers. Action nodes include record writes, HTTP calls to any URL with auth and retry, native connector actions (post to Slack, send DocuSign, create Stripe charge, etc.), data transforms (parse, format, join, split, lookup), approval gates, timer actions (wait N days), task creation, and alert emission. Logic nodes include branches (up to 10 conditions per branch, up to 20 branches per decision), loops over list fields with bulk-action limits, sub-flow calls, error handlers (retry, skip, abort, route, notify), and code-block actions (sandboxed JavaScript with typed input/output). For logic that resists canvas expression, the code-block and HTTP-action extensibility covers most remaining cases.
How fast does the workflow engine execute, and does it drop runs under load?
Trigger-to-start latency is sub-second on native triggers (record changes, external connector events, inbound webhooks). The engine evaluates matching flows on the write path within milliseconds and starts executions within sub-second. The user updating a record sees the automation effect before they pivot to the next task. The engine guarantees at-least-once delivery: every triggered flow executes at least once even under system restart, deploy, or temporary database connectivity blips. The guarantee holds through durable queues and transactional state writes. Actions that write to external systems carry idempotency keys so retries do not produce double charges, double documents, or double emails. The execution pool scales horizontally based on queue depth so peak-hour triggered flows (end-of-quarter close, campaign send, provisioning burst) run with no degradation to steady-state flows. Per-tenant fairness prevents one tenant's burst from starving another tenant's steady-state execution.
What happens when a step in a flow fails?
Transient failures (external API 500, rate limit hit, network blip) retry on exponential backoff: 1s, 5s, 30s, 2m, 10m, 1h. Persistent failures (invalid data, authentication expired, destination constraint violated) stop retrying and route to the dead-letter queue with the trigger payload, the state at failure, the error details, and the full step trace. The RevOps lead reviews the dead-letter queue, fixes the root cause (data correction, mapping adjustment, auth refresh), and replays the failed execution. Nothing drops silently. Error handlers attach to any step with configurable behavior: retry with backoff, skip and continue, abort the flow, route to a recovery branch, notify a user. The error handler is a first-class part of the canvas rather than an afterthought in a settings page. Each flow carries an execution timeout (default 15 minutes, configurable) so a runaway loop or hung external call does not consume engine capacity indefinitely.
How does Strkr handle flow versioning and rollback when a published flow has a bug?
Every save of a flow creates a version with a git-like diff showing nodes added, nodes removed, parameters changed, and connections rewired. The author reviews the diff on hover before publishing. Rollback to any prior version is a one-click action: the prior version publishes as the current running version while the forward versions remain in history for subsequent re-publish. The version history retains every version indefinitely. Combined with three environments per tenant (dev, stage, prod), the posture lets authors experiment freely in dev, test in stage against stage data, and promote to prod with approval. A flow in dev cannot touch prod records. Each environment has its own connector credentials and configuration; the flow definition travels across environments while the configuration swaps per environment, so no redevelopment is required per environment. Dry-run test mode runs flows against test cohorts (A through D by criticality) with mocked external connectors and no persistent writes before publish.
What observability does Strkr provide for production flows?
Each flow surfaces a dashboard with execution count (24h, 7d, 30d), success rate, average duration, 95th percentile duration, error rate, and dead-letter queue count. Alerts fire on success rate below configured thresholds. Every flow execution logs with the trigger payload, final outcome, duration, and full step trace; the trace captures each step's input and output, the branches taken, the external calls with request and response bodies, and the duration per step. The log is searchable by any field: triggered contact, triggered account, duration above a threshold, outcome type, specific error class. SLO tracking surfaces compliance against targets (99 percent success rate default, 95th percentile duration below 5 seconds default, dead-letter rate under 0.1 percent default); breaches route to the flow owner. A floor-level dashboard rolls up platform health across every production flow for platform admins. Flow metrics export to BI tools (Looker, Tableau, PowerBI, Metabase) through the standard reporting API so RevOps leads can build custom dashboards without CSV exports.
