Every workflow starts with exactly one trigger, and the trigger decides what kind of automation you are building.

An Event Trigger listens to something happening in your account. Record created and record updated on any object, such as People, Companies, Deals, or Tickets. Row created and row updated on any custom table. Contact created and contact updated. Conversation ended, conversation idle, and feedback captured, which come from a specific agent you select on the trigger. Integration events, such as a new Stripe checkout, a HubSpot deal stage change, a new Google Sheets row, or a new file in a Drive folder. And incoming webhook, covered further down.

A Scheduled Trigger runs on a clock in the timezone you choose. Weekday mornings at nine, the first of the month, every four hours. This is where recurring reviews live, like a Monday sweep of every mandate that has not moved in fourteen days.

Two things worth knowing early. The conversation triggers fire per agent, so you select which agents feed the workflow. And conversation idle needs idle enabled on the agent's channel, since the idle event is what the channel emits after a quiet period you define.

The palette is grouped so you can find things by intent.

AI and intelligence. The AI Agent node is the workhorse. You give it a model, instructions, a prompt, and the table permissions it needs, and it reasons over the input and writes back to your CRM through its own tools. In the lead scoring example the AI Agent reads the new record, evaluates it against your rubric, and updates the Lead Score and Score Reason fields itself. Agent Capture is the narrower version, used when you want an AI model to pull named values out of messy text into variables. Transcribe Audio turns a recording into text, with optional speaker separation. File Analysis runs OCR plus analysis on a PDF or an image, and gives you both the raw text and a structured read of it, which is how a signed mandate document becomes usable data.

CRM. Data Action is direct, deterministic record work. Create, update, delete, search, fetch by id, or move a record to a different record type. Create Record Activity logs a note, call, meeting, email, or WhatsApp activity on a record, so the timeline reflects what the automation did.

Data and logic. Data Transformer uses a model to normalize or reshape data, which is ideal for turning a raw payload into clean fields. Conditional Routing branches the path, evaluated in natural language, so a condition reads like “the mandate is above ten million” rather than code. Loop iterates over a list and gives you a body path, a completed path, and a separate path for when the list comes back empty. Break exits a loop early. Change Workflow Status sets another workflow live or back to draft, which is how you build seasonal or campaign automations that switch each other on.

Integration and messaging. API Call hits any endpoint, with separate success and failure paths so a bad response routes somewhere useful instead of stopping everything. Outgoing Webhook pushes context to an external system. Send Message replies inside an active conversation, which pairs naturally with the conversation idle trigger. Send WhatsApp Message sends an approved template to a phone number or a People record with no conversation required.

Variables are how one step hands work to the next, and they behave as text substitution. You write {variable_name} in any field and Frontline replaces it with that value when the workflow runs.

There are three kinds worth separating in your head.

Trigger variables arrive with the event, at no setup cost. A record trigger carries {created_record} or {updated_record}. An incoming webhook carries {webhook_payload}. An integration event carries {trigger_payload}. Conversation ended carries {conversation_transcript} and {contact_info}, which is exactly why post-conversation enrichment is so easy. Feedback captured adds {feedback}.

Node variables are the results of previous steps. Every node stores its output, and you reference it downstream by that node's name on the canvas. An API Call can also capture specific values from its response into named variables, so {mandate_value} is available later without carrying the whole payload around. AI nodes capture into variables you define. A Loop exposes the current item, its index, and the list length while the body runs.

Workflow variables are the ones you create for this workflow. You name them, you describe them, and a node fills them in. Create first_name, email, and mandate_size once, and every node from that point can read them.

One rule keeps this simple. Variables are flat values, so when a payload arrives as a blob you extract the fields you need with a Data Transformer or an Agent Capture node first, then use those clean variables everywhere else. That extra step is also what makes the run readable later, because you can see the exact values that were pulled.

An incoming webhook is a Frontline hosted endpoint that any outside system can post to. A form, a payment provider, a meeting recorder, a legacy CRM, a script.

You create it under incoming webhooks and get three things. A URL, an access token, and a Test Webhook button so you can fire a sample payload and confirm the shape before you build anything against it. You can name and describe it, turn authentication on or off, and flip it inactive as a kill switch that stops accepting calls while keeping the full history intact.

To use it, add an Event Trigger set to incoming webhook and select which webhook feeds it. The full body arrives as {webhook_payload}, and every delivery is recorded as an event with the payload, the source, and the workflows it triggered. When something looks wrong, the event history tells you whether the call arrived at all, which is usually the fastest way to separate a sender problem from a workflow problem.

The Harrington version of this is a meeting notetaker. The call ends, the notetaker posts the notes to your webhook, a File Analysis or Data Transformer node pulls out the commitments, a Data Action updates the Deal, and Create Record Activity logs the recap on the record.

The Logs tab is the run history for that workflow. Every execution shows a Run ID, when it started, its status, the run time, and the AI credits it consumed. You can filter by date range and by status, so a bad afternoon is easy to isolate.

Open any run and the Execution Details panel gives you two views. The Summary is the headline: run id, status, start and completion, duration, and credits. Node Runs is where the real answers live. Each node in that execution is listed with its own status, its own duration, and its own credit cost, and each one has View Input and Output.

Open that, and for an AI node you see the model, the temperature, the instructions, the prompt, the table tools it had, and the context variables it was given, alongside its chain of thought, every tool call with parameters, and the result each call returned. When lead scoring gives James a zero, you are not guessing. You can read the reasoning, see that the email was a generic domain and the company fields were unknown, and decide whether to fix the rubric or fix the intake form.

Per node timing and per node credits also make optimization concrete. If one AI Agent accounts for most of the duration and most of the cost, that is the node to simplify.

Analytics is the aggregate view over the date range you pick. Total runs, completed, failed, and pending. Average credits per run and total credits. Runs by time of day and runs by day of week. A daily bar chart of credit usage.

Use it for two questions. Is this automation healthy, which the failed count answers immediately. And is this automation worth what it costs, which average credits per run answers in a number you can compare across workflows.

You do not have to start from a blank canvas.

Talk to Max about the outcome you want in plain language. Describe the automation you are trying to build, the objects involved, and the conditions, and use that to shape the design before you touch a node.

For teams that live in a terminal, the Frontline CLI exposes the same workflow API that the canvas uses. Create a workflow, add nodes, connect edges, define variables, activate it, read the graph, and pull run logs, all as commands. Point a coding agent such as Claude Code at it and the loop gets fast, because the agent can read the current graph, make a change, trigger a run, read the node level input and output, and correct itself. That is the debugging loop the Node Runs view gives you in the app, running unattended.

The CLI is also how workflows become reviewable. You can keep the definition of an automation in a repo, diff a change, and rebuild the same workflow in another account.

Pick one thing your team currently does by hand every day and make that your first workflow.

For Harrington Family Office, the honest first build is lead scoring. An Event Trigger on record created in Leads, one AI Agent node with a clear rubric and permission to update the record, and nothing else. Save it, set it live, send one test lead, then open the run and read the reasoning.

Once you trust that loop, everything else is additive. Add Conditional Routing so large mandates route straight to a senior advisor. Add Create Record Activity so the timeline shows the score. Add a conversation ended workflow so every WhatsApp thread enriches the record on its own. Add a conversation idle workflow with Send Message so James gets a gentle nudge instead of being forgotten.

The pattern that scales is small workflows that each do one job well, wired to the events you already generate.