---
title: "vPlan Integration"
description: "vPlan is visual work planning and scheduling for manufacturing and project teams from a Dutch vendor. Agents create and schedule cards, manage boards, resources and collections, and keep the plan current with orders and capacity from other systems."
url: https://flowrunner.ai/integrations/vplan
date_modified: 2026-09-04T14:21:17-07:00
---

# vPlan

[Project Management](https://flowrunner.ai/integrations/category/project-management-productivity)

vPlan is visual work planning and scheduling for manufacturing and project teams from a Dutch vendor. Agents create and schedule cards, manage boards, resources and collections, and keep the plan current with orders and capacity from other systems.

69 actions · API key · available

[vPlan website](https://vplan.com/) · [Platform Documentation](https://docs.api.vplan.com) · Capability data verified 2026-08-18

1.  A confirmed production order arrives from the ERP
2.  Agent reads the order lines, quantities and the activities each one requires
3.  Create Collection opens the order as the parent the work will be planned under
4.  Create Card plans each piece of work under that collection, against an activity, a stage and a resource
5.  Get Board Capacity compares the newly planned load against what the board can absorb in the period
6.  Agent posts the overbooked days with the orders now competing for the same resource
7.  The planner decides which order takes the capacity and which one moves

## What This Integration Enables

vPlan is planning for places where the plan meets something physical. A resource is a person or a machine, not a seat license. A collection is the order or the job, and a card is a planned piece of work underneath it, which means the board is not a metaphor for work, it is a claim on capacity that exists. Capacity itself is scoped to a board rather than to the whole environment, so the question vPlan answers is always local: can this board absorb this work in this period.

FlowRunner agents keep that plan honest without pretending to own it. They open collections from confirmed orders, place cards against activities and stages, move work through stages as it progresses, record schedule deviations when leave or downtime is approved elsewhere, and read the board's capacity as the plan changes rather than after it breaks. Where they stop is precise and worth stating plainly: vPlan holds the capacity, but the customer promise date lives in the system the order came from. An agent that can see one and not the other should not be choosing which order slips, and that is exactly the boundary a [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) step exists to hold.

### Without FlowRunner

**Orders retyped onto the board**: The ERP knows the order and somebody rebuilds it as cards by hand

**Overbooking discovered on the floor**: The plan looks fine until the week arrives and two jobs want the same machine

**Availability out of date**: Leave, overtime and machine downtime reach the planner after the plan is already made

### With FlowRunner

**The order arrives as a plan**: Each order becomes a collection with its cards already placed against activities and stages

**Contention surfaces while it is still on paper**: Planned load is checked against board capacity as the work lands, not when it starts

**Availability follows reality**: Approved leave and scheduled downtime become deviations against the resource they affect

## Use Case Scenarios

### A confirmed order lands on the board as work, not as a note

An order is confirmed in [Acumatica](https://flowrunner.ai/integrations/acumatica) or [NetSuite](https://flowrunner.ai/integrations/netsuite). The agent opens it in vPlan with Create Collection, because a card belongs to a collection and cannot be created against a board directly. Each order line becomes a card through Create Card, placed against the activity that describes the kind of work and the stage it starts in. List Board Labels supplies the board's own labels, which belong to that board rather than to the environment, so the same name on another board is a different record and the agent resolves it per board. Then Get Board Capacity is read for the affected period, and anything that pushes a resource past what it can absorb is reported rather than silently planned.

### Availability that keeps up with the shop floor

Leave is approved in an HR system and planned maintenance is scheduled in a maintenance system. Both change what the plan can promise, and neither of them is where the planner looks. The agent turns each one into a schedule deviation against the affected resource, whether that resource is a person or a machine, so the working pattern the board plans against reflects the exception. Get Resource Schedule confirms the result. When a deviation is canceled, Delete Schedule Deviation returns the resource to its normal pattern. The distinction that matters here is that a user is not a resource in vPlan: a login and a thing work is planned against are separate records, and the agent keeps them separate.

### Progress that flows back without anyone reporting it

As work moves, the agent reads one order's cards cheaply with List Collection Cards rather than filtering the whole board, moves cards between stages with Update Card, ticks checklist items with Update Checklist, and posts context with Create Comment. Because comments and attachments are top level resources in vPlan rather than nested under a card, the record being commented on is named in the request itself, which the connector handles. A daily summary lands in [Slack](https://flowrunner.ai/integrations/slack) and the completed work is appended in [Google Sheets](https://flowrunner.ai/integrations/google-sheets). The agent also reads List API Messages on a schedule, because vPlan records warnings against requests that otherwise succeeded, and a workflow that never reads them will not notice a deprecation until it becomes an outage.

## Human-in-Loop Highlight

The costly moment in vPlan is not a delete, although the deletes here cascade hard: Delete Collection removes the cards planned under it, Delete Board removes everything planned on it, and Delete Space removes everything in it. The moment that actually costs money is quieter. When Get Board Capacity comes back short, somebody has to decide which order gives up its slot, and the agent has only half the information needed to decide. vPlan knows the capacity. It does not know which customer was promised what, because that lives in the ERP the order came from. Planning the card anyway is not an error the API will report; it is a plan that looks complete and cannot be executed. So the agent stops there and puts the contention in front of the planner: "Order 44810 needs 18 hours on the CNC cell in week 12. The cell has 6 hours left after order 44772 and a maintenance deviation on Thursday. Move 44810 to week 13, split it across both weeks, or bump 44772 and tell me which cards to move?" The planner answers, and the agent executes the answer with Update Card, then posts the resulting capacity so the decision is on the record. The scheduling arithmetic is the agent's. The promise is not.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

69 actions

### Account

2

-   **Get Current Authentication** Returns what the configured key is and what it can reach. vPlan offers this as a connection test, which makes it the cheapest way to check a credential.
-   **List API Messages** Returns the warnings and notices vPlan recorded against recent third party requests. A request can succeed and still leave a deprecation or a data warning here, so this is worth reading on a schedule.

### Boards

6

-   **List Boards** Returns the boards in the environment. A board is the planning surface that stages, cards and capacity all hang off.
-   **Get Board** Returns one board.
-   **Create Board** Adds a board to the environment.
-   **Update Board** Changes a board's name, description or other properties.
-   **Delete Board** Deletes a board and everything planned on it. Destructive enough to belong behind a review step.
-   **Get Board Capacity** Returns how much work a board can absorb over time. Capacity is board scoped in vPlan, so this is the only place the question is answered.

### Board Labels

4

-   **List Board Labels** Returns a board's labels. Labels belong to a board rather than to the environment, so the same name on two boards is two different records.
-   **Create Board Label** Adds a label to a board.
-   **Update Board Label** Renames a label or recolors it.
-   **Delete Board Label** Removes a label from a board.

### Board Views

3

-   **List Board Views** Returns a board's saved views, which are the filtered layouts people actually work through.
-   **Create Board View** Adds a saved view to a board.
-   **Delete Board View** Removes a saved view from a board.

### Board Checklists

3

-   **List Board Checklists** Returns the checklist templates defined on a board. This is the board scope, distinct from collection checklists and the environment listing.
-   **Create Board Checklist** Adds a checklist template to a board.
-   **Delete Board Checklist** Removes a checklist template from a board.

### Stages

5

-   **List Stages** Returns the stages, which are the workflow steps cards move through.
-   **Get Stage** Returns one stage.
-   **Create Stage** Adds a stage that cards can move through.
-   **Update Stage** Changes a stage.
-   **Delete Stage** Deletes a stage.

### Activities

5

-   **List Activities** Returns the activities, which are the kinds of work a card can represent.
-   **Get Activity** Returns one activity.
-   **Create Activity** Adds an activity.
-   **Update Activity** Changes an activity.
-   **Delete Activity** Deletes an activity.

### Resources

6

-   **List Resources** Returns the resources, which are the people and machines work is planned against.
-   **Get Resource** Returns one resource.
-   **Create Resource** Adds a resource that work can be planned against.
-   **Update Resource** Changes a resource.
-   **Delete Resource** Deletes a resource together with its schedule.
-   **Get Resource Schedule** Returns a resource's working schedule, which is what decides its available capacity.

### Schedule Deviations

3

-   **List Schedule Deviations** Returns the exceptions to normal working patterns, either for one resource or across the environment.
-   **Create Schedule Deviation** Records an exception to a resource's normal working pattern, such as a day of leave or a period of overtime.
-   **Delete Schedule Deviation** Removes a deviation, returning the resource to its normal pattern for that period.

### Collections

9

-   **List Collections** Returns the collections, which are the orders or jobs that cards belong to. A collection is closer to an order than to a folder.
-   **Get Collection** Returns one collection.
-   **Create Collection** Adds a collection, which is the order or job that cards are planned under.
-   **Update Collection** Changes a collection.
-   **Delete Collection** Deletes a collection and the cards planned under it, which takes the shop floor record of that order with it.
-   **List Collection Cards** Returns the cards planned under one collection. The cheap way to read an order's work without filtering the whole board.
-   **List Collection Checklists** Returns the checklists attached to one collection.
-   **Create Collection Checklist** Attaches a checklist to a collection.
-   **Delete Collection Checklist** Removes a checklist from a collection.

### Cards

5

-   **List Cards** Returns the cards, which are the planned pieces of work.
-   **Get Card** Returns one card.
-   **Create Card** Plans a card under a collection. A collection has to exist first, because cards are not created against a board directly.
-   **Update Card** Changes a card, which is also how it is moved between stages or reassigned to another resource.
-   **Delete Card** Deletes a card from the plan.

### Comments and Attachments

6

-   **List Comments** Returns comments. Comments are a top level resource in vPlan rather than nested under a card.
-   **Create Comment** Adds a comment. Because comments are top level, the record being commented on is named in the request body.
-   **Delete Comment** Removes a comment.
-   **List Attachments** Returns attachments, which like comments are top level rather than nested under a card.
-   **Add Attachment Link** Attaches a link to a card or a collection, which is the reliable path from a workflow.
-   **Delete Attachment** Removes an attachment.

### Checklists

3

-   **List Checklists** Returns every checklist in the environment. The third checklist scope, alongside board templates and collection checklists.
-   **Get Checklist** Returns one checklist with its items.
-   **Update Checklist** Changes a checklist, which is how its items get ticked off as work progresses.

### Groups, Users and Spaces

9

-   **List Groups** Returns the resource groups, which is how resources are gathered into teams or cells.
-   **Create Group** Adds a resource group.
-   **Delete Group** Deletes a resource group. The resources in it are not deleted.
-   **List Users** Returns the people who can sign in to vPlan. A user is not a resource: a resource is something work is planned against and need not be a person.
-   **Get User** Returns one account.
-   **Update User** Changes an account.
-   **List Spaces** Returns the spaces, which are the top level partitions an environment's boards live in.
-   **Create Space** Adds a space.
-   **Delete Space** Deletes a space and everything in it.

## Frequently Asked Questions

### What can FlowRunner do with vPlan?

FlowRunner agents can run Get Current Authentication, List API Messages, and List Boards in vPlan, plus 66 more actions.

### Does connecting vPlan to FlowRunner require OAuth?

No. vPlan connects to FlowRunner with an API key, no OAuth flow required.

### Can vPlan trigger a FlowRunner workflow automatically?

vPlan doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

**Work at vPlan?** This integration exposes vPlan 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/vplan. Site index: https://flowrunner.ai/llms.txt
