--- title: "Pneumatic Integration" description: "Pneumatic is workflow and SOP automation built around turning a written procedure into live, assigned work. Agents launch workflows from templates, complete and reassign tasks, fill form fields and start flows when a Pneumatic workflow moves." url: https://flowrunner.ai/integrations/pneumatic date_modified: 2026-09-04T14:52:04-07:00 --- # Pneumatic [Productivity](https://flowrunner.ai/integrations/category/project-management-productivity) Pneumatic is workflow and SOP automation built around turning a written procedure into live, assigned work. Agents launch workflows from templates, complete and reassign tasks, fill form fields and start flows when a Pneumatic workflow moves. 1 trigger · 95 actions · API key · available [Pneumatic website](https://pneumatic.app/) · [Platform Documentation](https://pneumatic.app/) · Capability data verified 2026-08-18 1. A new customer, order, or case appears in the system of record and owes the business a procedure 2. Get Template Fields reads what the template's kickoff form expects before anything is filled in 3. The agent resolves the people and groups involved with List Users and List Groups so the run starts with real owners 4. Run Template starts the workflow with the kickoff filled in, turning the written procedure into live, assigned work 5. On a schedule, List Tasks reads what is outstanding and who is holding it, and Count Workflows shows where work is piling up 6. The holder of an overdue step is reminded, with the workflow's own comment thread carrying the context 7. When a step needs somebody outside the company, a person approves the guest before Set Task Guest Performer emails them a working link ## What This Integration Enables Pneumatic's model is worth stating plainly, because everything useful follows from it. A template is the written procedure. A workflow is one live run of it. Run Template is the operation most flows want, since it turns a procedure into a run with real people assigned, and List Tasks is the other, since it is the live list of what is outstanding and who holds it. A task can be held by a person, by a whole group so anybody in it can pick the work up, or by a guest outside the account entirely. A run can be snoozed until a date, returned to an earlier step for rework, or finished early where the template allows it. Every action here is built and verified against Pneumatic's own API. The division of labor is what makes this connector interesting rather than redundant. Pneumatic holds the human procedure and the record of who owes what. FlowRunner drives the systems on either side of it, and supplies the judgment the procedure assumes somebody will apply. An agent reads a case from the source system, launches the right template with the kickoff already filled, watches for steps that stall, completes the ones that are purely mechanical with Complete Task, and pulls a person in at the ones that are not. That is [Orchestration as a Service](https://flowrunner.ai/concepts/orchestration-as-a-service) working the way it is supposed to: FlowRunner does not replace the process a team already wrote down, it runs the systems around it and holds the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) points where a person still has to decide. ### Without FlowRunner **The procedure and the systems are separate**: The SOP says what to do, and somebody retypes the data into the tools that actually do it **Started by memory**: A run begins when a person remembers it should, which means some never begin at all **Stalls surface in the standup**: A step sitting with somebody on vacation is found in a meeting rather than by the process itself ### With FlowRunner **The procedure starts itself**: The upstream event fills the kickoff form and launches the run with owners already assigned **Systems stay in step with the steps**: Completing a task feeds the connected tools, and what those tools return feeds the next step **Stalls are exceptions with an owner**: Outstanding work is read on a schedule, and the ones that need a decision reach a person directly ## Use Case Scenarios ### Onboarding that starts from the deal, not from a reminder A deal closes in [HubSpot](https://flowrunner.ai/integrations/hubspot) or an order lands in [NetSuite](https://flowrunner.ai/integrations/netsuite). The agent reads Get Template Fields to learn exactly what the onboarding template's kickoff form expects, maps the deal's values onto those fields, resolves the account manager and the implementation group with List Users and List Groups, and calls Run Template. The run exists within seconds of the deal closing, with the right people already holding the first steps. As the run progresses, the agent completes the mechanical steps itself with Complete Task, supplying the output fields the step collects, and leaves the ones that need a conversation to the people who own them. A digest of where every active onboarding has reached posts daily to [Slack](https://flowrunner.ai/integrations/slack). ### The stall report that names a cause Once a day the agent calls List Tasks for outstanding work and Count Workflows grouped by who holds the current step. A stalled run is not interesting on its own; the reason is. So for each one the agent reads List Workflow Events, which is the audit trail and the comment thread in one feed, and works out what it is actually looking at. A step waiting on somebody who is on vacation is one thing, and the agent can see that because Set Vacation hands their tasks to whoever covers them. A step waiting on information that never arrived is another, and the agent can go and get it from the source system, then call Complete Task with the field filled. A run that should never have started is a third, and that one goes to a person. Get Dashboard and Get Highlights turn the pattern across all of it into a weekly read rather than a daily scramble. ### Rework handled as rework A quality check at the end of a procedure fails: the file is wrong, the address does not validate, the amount does not reconcile against [Xero](https://flowrunner.ai/integrations/xero). Rather than closing the run and starting a new one, which loses everything recorded against it, the agent calls Return Workflow To Step, naming the step the work has to go back to, and Comment On Workflow to say why in the thread the assignee will read. Where the check failed because of something the agent can fix, it fixes it first and says so. Where a step was completed in error, Revert Task undoes it and sends the run back to it. The history stays intact, which matters later when somebody asks why this case took three weeks. ## Human-in-Loop Highlight Set Task Guest Performer hands a task to somebody outside the account by email address, and Pneumatic sends them a link that lets them work that task without an account. That is genuinely useful, and it is the operation on this connector that reaches furthest outside the company. A supplier confirming a shipment date, a client approving a proof, a contractor filling in a compliance field: all of them become reachable without provisioning anyone. It is also the operation an agent should never decide on alone, because the agent is choosing who gets a working door into a live procedure, and the email address it is acting on usually came from a form or a record rather than from anybody's deliberate decision. So the agent prepares everything and stops. It posts to the process owner: "Step 4 of run 'Vendor onboarding, Northwind' is waiting on a certificate of insurance. The vendor contact on the record is ops@northwind.example. Adding them as a guest performer emails that address a link that lets them open and complete this step without an account, and the step's fields include the bank details captured at kickoff. Add this guest, send it to the internal procurement group instead, or hold?" The owner answers. If the answer is the internal group, the agent calls Set Task Group Performer and nobody outside sees the run at all. What the agent contributed was speed and completeness. What the person contributed was the decision about who is allowed in. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via email Human decides Agent resumes with decision ## Agent Capabilities 95 actions ### Account 12 - **Get Account** Retrieves the account's settings and details. - **Get Plan** Retrieves the billing plan and its limits. Most of this API stops answering once a paid subscription lapses, so this is the first read when calls start failing for no obvious reason. - **Get Current User** Retrieves the person the token belongs to. Everything this connection does is done as that person, with their permissions. - **Get User Counters** Retrieves the signed in person's counts of waiting tasks and unread items, which is the cheapest way to tell whether anything needs attention. - **List Contacts** Retrieves the signed in person's contacts, who are the people they can hand work to. - **Set Vacation** Puts somebody on vacation, or brings them back. While they are away their tasks are handed to whoever covers them, so this reassigns real work. - **List Notifications** Retrieves the signed in person's notifications. - **Get Notification Count** Retrieves how many notifications are waiting, without reading them. - **Delete Notification** Removes one notification from the signed in person's list. - **List API Keys** Retrieves the API keys on the account, or on one person. Treat anything it returns as a secret. - **Create API Key** Issues an API key for the account or for one person. The key is returned once and cannot be read back, so a workflow has to store it immediately. - **Delete API Key** Revokes an API key, and anything still using it stops working at once. ### Users 10 - **List Users** Retrieves the people on the account, filterable by status, type, and group. - **Get User** Retrieves one person by their identifier. - **Get Active User Count** Retrieves how many people currently count against the plan's seat limit. - **Create User** Adds somebody to the account. On a paid plan this can consume a seat and change what the account is billed. - **Update User** Changes somebody's details, sending only the fields a workflow fills in. - **Set User Admin** Grants or removes account administrator rights, which reach everything including billing. - **Delete User** Removes somebody from the account. Their work should be handed over first, because tasks still assigned to a removed person can strand a workflow. - **Reassign User** Hands everything one person is responsible for to somebody else. This is the operation that runs before a removal. - **Count User Workflows** Retrieves how many workflows one person is currently involved in, which is how a workflow tells whether removing them would strand anything. - **List User Privileges** Retrieves what the signed in person is allowed to do on this account. ### Groups 6 - **List Groups** Retrieves the groups on the account. A group can hold a task as a whole, so anybody in it can pick the work up. - **Get Group** Retrieves one group with its members. - **Create Group** Creates a group and puts people in it. - **Update Group** Renames a group or changes who is in it. Supplying a member list replaces the whole membership rather than adding to it. - **Delete Group** Deletes a group. Tasks handed to that group can be stranded, so the count of dependent workflows is worth reading first. - **Count Group Workflows** Retrieves how many workflows currently depend on a group. ### Templates 15 - **List Templates** Retrieves the workflow templates on the account. A template is the written procedure; a workflow is one run of it. - **Get Template** Retrieves one template in full, including its kickoff form and every step. - **Get Template Steps** Retrieves just a template's steps, which is where the step names a workflow can be returned to come from. - **Get Template Fields** Retrieves the fields a template collects across its kickoff form and its steps. The read that happens before Run Template, so the kickoff is filled correctly rather than approximately. - **Run Template** Starts a workflow from a template. This is the operation most flows want, since it turns a written procedure into a live run with real people assigned. - **Clone Template** Duplicates a template, which is how a variant is started without disturbing the original. - **Delete Template** Deletes a template. A run already under way depends on its steps, so what is still live is worth checking first. - **Create Template From Name** Asks Pneumatic to draft a template from nothing but a name, using its own generator. A quick first draft for somebody to edit. - **Create Template From Steps** Drafts a template from a name and a list of step names, which is the quickest way to turn a checklist somebody already wrote into a runnable procedure. - **List System Templates** Retrieves Pneumatic's own library of ready made templates. - **List System Template Categories** Retrieves the categories that library is organized under. - **Import System Template** Copies a template out of Pneumatic's library into the account, where it can be edited and run. - **List Public Templates** Retrieves the account's templates that have been published for people outside it to run. - **Export Templates** Exports the account's templates as structured data, which is how a procedure library is backed up or moved. - **List Template Integrations** Retrieves which integrations are connected to the account's templates, or to one of them. ### Workflows 12 - **List Workflows** Retrieves workflows, which are the live runs of templates, filterable by status, template, or who is holding the current step. - **Get Workflow** Retrieves one workflow in full, including where it has got to and who is holding it. - **Update Workflow** Changes a running workflow's name, urgency, due date, or kickoff values. - **Delete Workflow** Permanently deletes a workflow run with everything recorded against it. - **Finish Workflow** Ends a workflow early without working through its remaining steps. Only templates marked finalizable allow it. - **Snooze Workflow** Pauses a workflow until a date, taking it off everybody's list until then. - **Resume Workflow** Wakes a snoozed workflow immediately rather than waiting for its date. - **Return Workflow To Step** Sends a workflow back to an earlier step, which is how rework is handled without losing the run's history. - **Comment On Workflow** Adds a comment to a workflow, attributed to the person the token belongs to. - **List Workflow Events** Retrieves everything that has happened in one workflow, which is its audit trail and its comment thread in a single feed. - **List Workflow Fields** Retrieves the field values collected across running workflows, which is how data captured by a procedure is read back out. - **Count Workflows** Counts running workflows grouped by who holds the current step, by which template step they are on, or by who started them. ### Comments 4 - **Update Comment** Rewrites a comment on a workflow or a task. - **Delete Comment** Permanently deletes a comment. - **Set Comment Reaction** Adds a reaction to a comment, or takes one off. - **Mark Comment Watched** Marks a comment as seen by the signed in person. ### Tasks 12 - **List Tasks** Retrieves the tasks waiting across the account's running workflows. The live list of what is outstanding and who holds it. - **Get Task** Retrieves one task in full, including its fields, its checklists, and everybody holding it. - **Complete Task** Marks a task done, which moves the workflow to its next step, and supplies the output fields the step collects. - **Revert Task** Undoes a completed task, sending the workflow back to it. - **Comment On Task** Adds a comment to a task, attributed to the person the token belongs to. - **Set Task Due Date** Sets when a task is due, or clears the date entirely. - **Set Task Performer** Puts somebody on a task, or takes them off. A task can be held by several people at once. - **Set Task Group Performer** Hands a task to a whole group, so anybody in it can pick the work up. The internal alternative when a guest is not the right answer. - **Set Task Guest Performer** Hands a task to somebody outside the account by email address. Adding a guest emails them a link that lets them work the task without an account, which is why this page's human gate sits here. - **List Task Events** Retrieves everything that has happened on one task, which is its audit trail and comment thread. - **Get Checklist** Retrieves a checklist attached to a task. - **Set Checklist Item** Ticks a checklist item off, or unticks it. ### Datasets 6 - **List Datasets** Retrieves the datasets on the account. A dataset is a reusable list a form field can draw its options from. - **Get Dataset** Retrieves one dataset with its items. - **Create Dataset** Creates a dataset, which form fields can then draw their options from. - **Delete Dataset** Deletes a dataset, and any field drawing its options from it loses them. - **Add Dataset Item** Adds one entry to a dataset, which is how a picker stays current with a source system. - **Delete Dataset Item** Removes one entry from a dataset. ### Fieldsets 4 - **List Fieldsets** Retrieves the fieldsets on the account. A fieldset is a reusable group of form fields several templates can share. - **Get Fieldset** Retrieves one fieldset with the fields inside it. - **Clone Fieldset** Duplicates a fieldset, which is how a variant is started without disturbing the original. - **Delete Fieldset** Deletes a fieldset, and any template using it loses those fields. ### Attachments 1 - **List Attachments** Retrieves the files attached across the account's workflows. ### Reports 2 - **Get Dashboard** Retrieves one of the six dashboard reports. Workflows and tasks each offer an overview, a breakdown, and a per step view, which together answer where work is piling up. - **Get Highlights** Retrieves the highlights feed, which is the account's recent activity summarized. ### Tenants 5 - **List Tenants** Retrieves the tenant accounts beneath a partner account. An ordinary account gets an empty list. - **Get Tenant Count** Retrieves how many tenants a partner account holds. - **Create Tenant** Creates a tenant account beneath a partner account. On a paid plan this can change what the partner is billed. - **Delete Tenant** Deletes a tenant account with everything inside it. - **Get Tenant Token** Retrieves a token that acts inside one tenant. A tenant token replaces the account key rather than accompanying it, so a connection holding one sees that tenant and nothing else. ### Webhooks 6 - **List Webhook Events** Retrieves every event this account can subscribe to, and the address currently subscribed to each. Pneumatic publishes its event list nowhere else, so this is the only way to learn the vocabulary. - **Get Webhook Event** Retrieves the address currently subscribed to one event, if any. - **Set Webhook Subscription** Subscribes an address to one event, or unsubscribes it. Pneumatic keeps exactly one address per event, so subscribing a second one replaces the first rather than adding to it. - **Set All Webhook Subscriptions** Subscribes one address to every event at once, or unsubscribes it from all of them, replacing whatever each event was pointing at. Worth reading the current subscriptions before calling it, since some of them may belong to somebody else's integration. - **Get Workflow Webhook Example** Retrieves a sample of exactly what a workflow event delivers for this account's own data, which is more useful when building than a generic example. - **Get Task Webhook Example** Retrieves a sample of exactly what a task event delivers, for this account's own data. ## Triggers 1 triggers ### Event Triggers 1 - **On Account Event** Fires when the chosen event happens anywhere in the Pneumatic account, with the event list read live from the account rather than from a fixed dropdown, since Pneumatic publishes no list of its own. Pneumatic keeps exactly one subscribed address per event, so a second trigger on the same event replaces the first, including a subscription somebody set up outside FlowRunner. The picker shows which events already have an address attached, so that takeover is visible before it happens rather than after. ## Frequently Asked Questions ### What can FlowRunner do with Pneumatic? FlowRunner agents can run Get Account, Get Plan, and Get Current User in Pneumatic, plus 92 more actions. ### Does connecting Pneumatic to FlowRunner require OAuth? No. Pneumatic connects to FlowRunner with an API key, no OAuth flow required. ### Can Pneumatic trigger a FlowRunner workflow automatically? Yes. Pneumatic supports 1 trigger that can start a FlowRunner workflow automatically. **Work at Pneumatic?** This integration exposes Pneumatic to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/pneumatic. Site index: https://flowrunner.ai/llms.txt