Onboard
Project ManagementConnect AI agents to Onboard.io, a customer onboarding project management platform. Agents create customer roadmaps and tasks with an assignee, update the customer-facing plan, and read the team and customer members behind each launch.
What This Integration Enables
Customer onboarding is the part of the funnel where the sale stops being a promise and starts being a project, and Onboard.io is built for exactly that handover. Its object model is small and honest: customers are the companies being onboarded, roadmaps are the launches, tasks live either on a roadmap or in a reusable global library, and team members are the people on your side of the project. FlowRunner connects to all four so a flow can spin up a launch when a deal closes, keep tasks in step with the systems where the work actually happens, and react to what changes inside Onboard.
That last part is the difference here. This connector has a real trigger. On Onboard Event registers a webhook subscription with Onboard for the event you choose and deletes it when the trigger is removed, so FlowRunner is genuinely notified rather than polling. Every delivery is verified with a hex HMAC-SHA256 signature computed over the raw JSON body and carried in the x-onboard-hmac-sha256 header, and deliveries that fail verification are rejected. That is a meaningfully better position than most connectors in this category, which either poll or accept unauthenticated posts. One wrinkle to know: Onboard sends no verification handshake when the subscription is created, so the first proof that the path works is the first real event.
Design around one asymmetry in the write surface. Task assignment is available when a roadmap task is created, since Create Roadmap Task takes an assignee, a due date, a category and an estimated time. There is no reassign action for a task that already exists on a roadmap: Update Task edits the global reusable task in the account library, not the instance sitting on a customer's launch. So flows should aim at creating the right task with the right owner rather than at shuffling ownership afterwards. Similarly, the two roadmap write actions accept a free-form object because the public API specification does not enumerate their request body, which means FlowRunner cannot validate what you send. That is the reason the gate on this page sits where it does.
Without FlowRunner
With FlowRunner
Use Case Scenarios
The launch exists before the kickoff call is booked
A deal moves to Closed Won in HubSpot. A flow calls Create Customer with the company name and the external identifiers that tie the Onboard record back to the CRM company, then Create Roadmap with the customer reference, the template for that product tier and a name that matches how the account team talks about the deal. It reads back the roadmap ID and writes it onto the CRM record, then posts the launch to the account channel in Slack with the assigned owner. By the time the account executive sends the handover email, the roadmap is already there, which is the difference between a kickoff call that reviews a plan and one that invents it.
Milestones that announce themselves
An On Onboard Event trigger is subscribed to task completion. When it fires, the agent calls Get Roadmap and List Roadmap Tasks to work out what the completed task unblocked and how much of the launch remains, and Get Customer to resolve the account. If the completed task closed out a whole section, it drafts the customer-facing note and sends it through Gmail to the customer contact, and posts the internal version to the account channel. If it merely moved things along, it logs quietly. The distinction matters: a customer who gets an email for every checkbox stops reading them, and a customer who gets one for every real milestone starts trusting them.
A roadmap built from the spreadsheet the implementation team already keeps
Implementation teams often keep the real sequence in a sheet, because that is where it can be argued about. A flow reads the rows from Google Sheets, calls List Tasks to see which of them already exist as reusable global tasks, calls Create Task for the ones that do not so the library grows rather than repeating itself, and then calls Create Roadmap Task for each row against the new launch with its assignee, due date and estimated time. Sections come across as section headers, and internal-only steps carry the internal flag so the customer view stays clean. The sheet stays the place the team designs the process; Onboard becomes the place it runs.
Human-in-Loop Highlight
Update Roadmap is the action that edits a document your customer is looking at. An Onboard roadmap is not an internal ticket queue, it is the shared plan a customer uses to know what is expected of them and when their launch will be done. Two facts make that write worth gating. First, the public API specification does not enumerate the request body for creating or updating a roadmap, so the action accepts a free-form object that FlowRunner passes through without being able to validate it, which means a wrong field name fails quietly and a right field name with a wrong value succeeds loudly. Second, the neighbouring action is Delete Roadmap, which Onboard documents as permanent and which cannot be undone. So the agent never rewrites a live launch on its own judgment. When something upstream implies the plan should change, a slipped dependency, a scope change on the deal, a phase that finished early, the agent gathers the evidence with Get Roadmap and List Roadmap Tasks and puts the proposed change in front of the account owner in full: "Acme's launch roadmap currently shows Phase 2 due 22 August. The integration task it depends on completed 6 days late. Proposed update: shift the Phase 2 due date to 30 August. The customer can see this roadmap. Apply?" The owner says yes, no, or gives a different date, and the agent calls Update Roadmap with exactly what was approved. Everything the agent could safely do without asking, resolving IDs, reading the task list, working out the dependency, it already did.
Agent Capabilities
22 actionsAccount
1- Get Account Retrieves the Onboard account record tied to your API key, including company name, defaults and related metadata. Useful as a connection test at the start of a flow.
Customers
6- List Customers Lists customers, meaning the companies being onboarded. Supports pagination. When a page number is supplied the response is a count, next, previous and results envelope; when it is omitted, Onboard returns a plain array of all records.
- Get Customer Retrieves a single customer by numeric ID, including name, website, external identifiers and timestamps. The external identifiers are what tie the record back to a CRM company.
- Create Customer Creates a new customer. Only the name is required. External identifiers let you link the customer to a CRM account or company record so the two systems can find each other later.
- Update Customer Updates fields on an existing customer. Only the fields you supply are changed, so a partial sync will not blank the rest of the record.
- Delete Customer Permanently deletes a customer by numeric ID. This cannot be undone.
- List Customer Members Lists the members associated with a specific customer, meaning the people on the customer's side, including name, email and external identifiers. Onboard marks the member create fields as read-only on this endpoint, so no add-member action is shipped.
Roadmaps
5- List Roadmaps Lists roadmaps, the customer onboarding projects that Onboard also calls launches. Supports pagination with the same envelope behavior as List Customers.
- Get Roadmap Retrieves a single roadmap by numeric ID, including name, status and related metadata. This is the call that turns a webhook object ID into a launch a person recognizes.
- Create Roadmap Creates a new roadmap. The request body fields are account specific and are not enumerated in the public API specification, so this action accepts a free-form object sent as the request body. Common fields include a customer reference, a template reference and a name.
- Update Roadmap Updates an existing roadmap, again accepting a free-form object because the body is not published. Only the fields you supply are changed. The roadmap is customer visible, so this is the write to keep a person on.
- Delete Roadmap Permanently deletes a roadmap by numeric ID. This cannot be undone.
Roadmap Tasks
2- List Roadmap Tasks Lists the tasks on a specific roadmap, including name, status, section flags, assignees and due dates. Paired with the trigger, this is how a flow works out what a completed task unblocked.
- Create Roadmap Task Adds a new task to a roadmap, supporting section headers, optional and internal flags, an assignee, a due date, a category and an estimated time. Assignment happens here, at creation, since the API exposes no reassign action for an existing roadmap task.
Global Task Library
5- List Tasks Lists the global reusable tasks in the account library. These are the definitions that can be added to roadmaps and templates. Supports pagination.
- Get Task Retrieves a single global task by numeric ID, including name, description, category, visibility and due-date settings.
- Create Task Creates a new global reusable task in the library. Only the name is required. Supports category, client visibility, due-date anchoring, estimated time, and the section, optional and internal flags.
- Update Task Updates fields on an existing global task. Only supplied fields change. Note that this edits the library definition, not an instance already placed on a customer's roadmap.
- Delete Task Permanently deletes a global task by numeric ID. This cannot be undone.
Team Members
3- List Team Members Lists the team members on your side of the project, including name, email, account type and status. Supports pagination.
- Create Team Member Creates a new team member. First name, last name, email and account type are required, and the account type sets the member's permission level.
- Invite Team Member Sends or resends the invitation email so a team member can activate their account. This puts a message in a real person's inbox, so drive it from a deliberate step rather than a broad sync.
Triggers
1 triggersEvent Triggers
1- On Onboard Event Fires when a chosen Onboard event occurs, covering roadmap and task changes, customer changes, completed workflows, submitted forms and more. Onboard registers a webhook subscription for the selected event when the trigger deploys and deletes it on teardown. Each delivery is verified with a hex HMAC-SHA256 signature over the raw JSON body, keyed with your API key and carried in the x-onboard-hmac-sha256 header, and deliveries that fail verification are rejected. Onboard sends no verification handshake at subscription time, so the first real event is the first confirmation the path works.
Frequently Asked Questions
What can FlowRunner do with Onboard?
FlowRunner agents can run Get Account, List Customers, and Get Customer in Onboard, plus 19 more actions.
Does connecting Onboard to FlowRunner require OAuth?
No. Onboard connects to FlowRunner with an API key, no OAuth flow required.
Can Onboard trigger a FlowRunner workflow automatically?
Yes. Onboard supports 1 trigger that can start a FlowRunner workflow automatically.
Start building with Onboard
$100 in credits. No card required. Connect in minutes.