--- title: "Neaktor Integration" description: "Neaktor is business process and project management where task models define fields and status workflows and tasks are instances of a model. Agents create tasks against the right model, move them through their workflow, mirror comments and report spent time." url: https://flowrunner.ai/integrations/neaktor date_modified: 2026-09-04T14:21:17-07:00 --- # Neaktor [Project Management](https://flowrunner.ai/integrations/category/project-management-productivity) Neaktor is business process and project management where task models define fields and status workflows and tasks are instances of a model. Agents create tasks against the right model, move them through their workflow, mirror comments and report spent time. 48 actions · API key · available [Neaktor website](https://neaktor.com/) · [Platform Documentation](https://neaktor.com/) · Capability data verified 2026-08-18 1. An external system reports that a step in the process has completed 2. List Task Models reads which model governs this kind of work and what fields it defines 3. List Tasks finds the open task the signal belongs to, filtered by model and status 4. Get Task Status Routing reads which transitions this specific task may actually make 5. Update Task writes the outcome into the model's fields before anything moves 6. Add Task Watchers puts the people who need to know on the task without making them responsible 7. The process owner approves the status move when the target status has no route back ## What This Integration Enables Neaktor is a business process platform wearing project management clothes, and the difference is the task model. A model defines which fields a task has and which statuses it may move between, and every task is an instance of one. That means Neaktor knows things a kanban board does not: whether a given move is permitted, whether it requires a condition to be met, and whether making it hands the task to somebody else. FlowRunner agents work with that structure rather than around it. They read models and their status routings, create tasks against the correct model with the fields it actually defines, move work through the workflow, mirror comments, write rows into a task's table fields, and pull spent time out for billing and reporting. This is where the orchestration argument gets concrete. A process definition is a description of which decisions are safe to make automatically and which are not, and Neaktor publishes that description through its API. An agent can read Get Task Status Routing and learn, for this task with these field values, exactly which doors are open. FlowRunner's [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) design uses that reading: the agent walks the transitions the model treats as routine, and stops at the ones the model treats as consequential. The judgment is not invented by the agent. It is read out of the process the company already designed. ### Without FlowRunner **The process lives in a document**: The workflow is written down somewhere, and what the tool enforces is whatever the last person clicked **Transitions guessed from the outside**: Anything scripted against the board assumes a move is legal and finds out at the write **Time and status reconciled by hand**: Spent time is exported into a spreadsheet before anyone can bill it or report on it ### With FlowRunner **The process is the model**: Tasks are created against the model that defines their fields and their legal moves, so the shape is enforced **Transitions checked before they are made**: The routing for that exact task is read first, so a forbidden or one-way move is known in advance **Time read where it was logged**: Spent time is pulled per task or per reporting window and lands in the system that needs it ## Use Case Scenarios ### Intake that lands in the right shape A request arrives from a form in [Typeform](https://flowrunner.ai/integrations/typeform) or an inbox watched through [Gmail](https://flowrunner.ai/integrations/gmail-service). The agent calls List Modules to fix the container, then List Task Models and Get Task Models By Ids to read the field definitions the intake model expects. It maps the submission onto those fields, resolves the assignee through List Users, and calls Create Task with the values passed as a field list rather than as loose properties. Add Table Rows writes the line items from the request into the task's table field. Create Comment records where the request came from, with the visibility set so the note stays internal. ### Comments that stay in one conversation The people doing the work live in a chat tool; the record lives in Neaktor. On a schedule, the agent reads List Task Comments for the tasks in an active project, posts anything new to [Slack](https://flowrunner.ai/integrations/slack), and writes replies back with Create Comment so the task history stays complete. Where a customer conversation is running over Neaktor's own connected channels, Send Telegram Message delivers the update to the chat the customer is already in. The point is not the mirroring, it is that nobody has to choose between a readable conversation and a complete audit trail. ### Spent time that reaches the invoice At the end of a reporting period, the agent runs Run Spent Time Report across a module or a project for the chosen window, then Get Task Spent Time on the tasks that need a per-person breakdown. The totals are assembled into a draft and posted for the delivery lead to check against what was actually agreed with the client. Once approved, the figures flow into a draft invoice in [Xero](https://flowrunner.ai/integrations/xero) or [QuickBooks Online](https://flowrunner.ai/integrations/quickbooks-online), and a copy of the breakdown lands in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the record. The agent assembles; the person signs off on the number before it leaves the building. ## Human-in-Loop Highlight Change Task Status is the operation that carries this connector's real weight, because in Neaktor a status move is not a column change. A task model's workflow can require a transition condition and can reassign the task as part of the move, and the routing can forbid a transition outright. So before any move, the agent calls Get Task Status Routing, which accounts for that specific task's field values rather than just the model's general shape, and reads what is genuinely available. When the target status still routes back to where the task is now, the agent moves it and carries on. When the routing shows no path back, or when the transition hands the task to a different owner, it stops and asks: "Task 4417 is ready to move from Legal Review to Contracted. The model's routing offers no transition back out of Contracted, and the move reassigns the task from Legal to Delivery. Confirm the move?" The process owner answers. The agent read the constraint out of the customer's own model rather than being told about it, which is why this gate holds up when the model changes. 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 48 actions ### Account 3 - **Get Current User** Retrieves the account the access token belongs to. Every permission check runs against that user, so this is the first thing to confirm when writes are being refused. - **List Users** Retrieves a page of users in the account. Assignees and comment mentions are identified by these user ids. - **Get Users By Ids** Retrieves several users at once by their ids, which is cheaper than one request per person when resolving the assignees on a batch of tasks. ### Modules and Projects 9 - **List Modules** Retrieves the modules in the account. A module is Neaktor's top level container, so projects, task models and tasks all live inside one and this is usually a flow's first call. - **Get Module** Retrieves one module by its id. - **Create Module** Creates a module. Modules are structural, so this is closer to configuring the workspace than to day to day work. - **List Projects** Retrieves a page of projects, optionally narrowed to one module. Projects group tasks inside a module. - **Get Project** Retrieves one project by its id, including its members. - **Create Project** Creates a project inside a module. The members added here are the people who can see and work on it. - **Update Project** Renames a project or replaces its member list. The member list replaces rather than appends, so send everyone who should remain. - **Add Project Managers** Adds managers to a project on top of whoever is already assigned. This is the additive operation of the pair. - **Set Project Managers** Replaces a project's manager list with the one supplied. Anyone not in the list stops being a manager, so read the project first. ### Task Models and Workflow 4 - **List Task Models** Retrieves the task models in the account. A model defines a task's fields and its status workflow, and Create Task needs one, so this is the second call most flows make. - **Get Task Models By Ids** Retrieves several task models at once by their ids, including their field definitions and statuses. This is what tells an agent the shape a task write has to take. - **List Status Routings** Retrieves which statuses a task in a given status may move to under a model's workflow. Read this rather than guessing, because a model can forbid a transition outright. - **Get Task Status Routing** Retrieves the status transitions available to one specific task, accounting for that task's own field values as well as the model's workflow. The read behind this page's human gate. ### Tasks 8 - **List Tasks** Retrieves a page of tasks filtered by module, task model, project, status or date. Neaktor also accepts a free form field filter object for matching on custom field values. - **Get Tasks By Ids** Retrieves several tasks at once by their ids, which is how a flow resolves a batch without one request per task. - **Create Task** Creates a task from a task model. The model decides which fields exist, so read it first and pass the values as a field list rather than as top level properties. - **Update Task** Updates a task's fields, assignee or dates. Only what is supplied is sent. Status moves go through Change Task Status instead, because that route carries the transition condition. - **Delete Task** Permanently deletes a task along with its comments and logged time. There is no soft alternative here, so treat it as a cleanup operation rather than a way to close work down. - **Change Task Status** Moves a task into a different status. A model's workflow can require a specific transition condition and can reassign the task as part of the move, which is why this route takes both and why it is the one worth gating. - **Link Task** Creates a link between two tasks, which is how Neaktor records that one depends on or relates to another. - **Update Task Link** Changes the kind of an existing link between two tasks. ### Watchers and Files 5 - **List Task Watchers** Retrieves the people watching a task. Watchers are notified of changes without being assigned the work. - **Add Task Watchers** Adds people as watchers on a task, so they see changes without being made responsible for them. The right way to keep a stakeholder informed without reassigning ownership. - **Remove Task Watchers** Removes people from a task's watcher list. They stop being notified but keep any other relationship to the task. - **Remove Task File** Removes a file from one of a task's file fields. The file is detached from the task rather than edited. - **Get Files By Ids** Retrieves file metadata by id, including the name and size, for a flow that needs to inspect attachments before acting on them. ### Comments 2 - **List Task Comments** Retrieves the comments on a task, including who was mentioned and any attached files. The read behind any conversation mirroring flow. - **Create Comment** Adds a comment to a task. The visibility setting decides who can read it, so a note meant for the internal team should not be left on the default. ### Custom Fields 2 - **List Custom Fields** Retrieves the custom fields defined in the account. Their ids are what Create Task and Update Task expect inside the field list. - **Get Custom Fields By Ids** Retrieves several custom fields at once by their ids, including their allowed values where the field is a list. ### Calendar 7 - **List Calendar Entries** Retrieves calendar events and reminders. Neaktor keeps both in one collection, distinguished by the kind on the entry itself. - **Get Calendar Entry** Retrieves one calendar event or reminder by its id. - **Create Calendar Event** Creates a calendar event. Events occupy a span of time, unlike reminders, which fire at a moment. - **Update Calendar Event** Updates an existing calendar event. - **Create Calendar Reminder** Creates a calendar reminder, which fires at a moment rather than occupying a span of time. - **Update Calendar Reminder** Updates an existing calendar reminder. - **Delete Calendar Entry** Permanently deletes a calendar event or reminder. ### Table Fields 4 - **Add Table Rows** Adds rows to a table field on a task. Neaktor tables are a field type, so the field id identifies which table on the task is being written to. - **Remove Table Rows** Removes rows from a table field on a task. - **Update Table Cell** Sets one cell of a table field on a task, identified by its row and column. The targeted write. - **Update Table Column** Sets the value of one column across every row of a table field. This writes many cells in a single call, so it is worth checking the target before running it. ### Time Reporting 2 - **Get Task Spent Time** Retrieves the time logged against one task, broken down by the people who logged it. - **Run Spent Time Report** Runs the spent time report across a module, project or task model over a reporting window. Choose a custom range to supply your own dates, otherwise the named period decides them. ### Messaging 2 - **Send Telegram Message** Sends a message through the Telegram integration configured on the Neaktor account. This delivers a real message to a real chat, so it is not safe to retry casually. See the \[Telegram\](/integrations/telegram) connector when the conversation should be handled directly rather than through Neaktor. - **Send Rocket Chat Message** Sends a message through the Rocket.Chat integration configured on the Neaktor account. This delivers a real message to a real channel and cannot be recalled from it. ## Frequently Asked Questions ### What can FlowRunner do with Neaktor? FlowRunner agents can run Get Current User, List Users, and Get Users By Ids in Neaktor, plus 45 more actions. ### Does connecting Neaktor to FlowRunner require OAuth? No. Neaktor connects to FlowRunner with an API key, no OAuth flow required. ### Can Neaktor trigger a FlowRunner workflow automatically? Neaktor doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Neaktor?** This integration exposes Neaktor 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/neaktor. Site index: https://flowrunner.ai/llms.txt