Run your team's process as workflows attached to real records.
FloForge holds the steps you already follow — intake, assignment, follow-up — in one place, along with the client and request records they act on. Open any run to see the step it is on, who owns it, and what it is waiting for.
Early access. FloForge is in active development — the pages below describe what is built today.
- Intake form receivedClient onboarding · 14 fields
- Create client recordWrites to Clients table
- Assign account ownerRound-robin · Accounts team
- Send kickoff checklistEmail · waits for reply
A run of the Client onboarding workflow. Step 3 is active; step 4 is queued behind a client reply.
CSV, HubSpot and Make.com all resolve to the same six records. Nothing gets a parallel copy of your data.
Define the record
Choose the fields the work depends on — text, number, date, select, reference, owner. This is the data every run reads and writes.
Lay out the steps
Order the actions: create, update, assign, notify, wait for reply. Each step names who owns it and what has to be true before the next one starts.
Watch the runs
Every run keeps its own history. Open one to see the current step, the owner, and what it is waiting on.
Bring your customer list across without asking anyone technical.
Bring what you already have
Upload a CSV exported from your spreadsheet or your current CRM. FloForge reads it in the browser — the file itself is never uploaded or stored.
Match the columns
Headings that clearly match a field are mapped for you and marked as suggestions. Anything ambiguous is left for you to decide, and columns you do not need stay out.
See the problems first
Missing names, unusable email addresses, dates FloForge cannot read, and rows that match something you already have — counted and explained before anything is written.
Import, then check the record
Added, updated, skipped and failed are counted from what the database actually did. Every row that did not make it is kept with the reason why.
Structure first, automation second.
A workflow is only as reliable as the data under it. You define the fields a record needs, then a workflow reads them, writes to them, and branches on them. When the process changes you edit the workflow — the records stay intact.
- Company
- Northline Freight
- Stage
- Onboarding
- Owner
- A. Reyes
- Start date
- 2026-08-24
- Contract
- AGR-1183
For work that repeats but still gets dropped.
- Client onboarding
- Intake, record creation, owner assignment, and the checklist that has to come back signed.
- Requests and approvals
- A request record, a reviewer, and a step that waits instead of relying on a reminder.
- Handoffs between teams
- Ownership changes are part of the workflow, so the trail stays with the record.
- Recurring internal ops
- Monthly closes, audits, renewals — the same steps, each run with its own history.
Start with the records you already keep in a spreadsheet.
Import them, see exactly what came in and what did not, and keep working from there.