---
title: "MatrixFlows Integration"
description: "MatrixFlows is the AI knowledge enablement and collaboration platform. Agents read table schemas, create and update records with comments, attachments, and images, work the inbox, and react to record events in real time."
url: https://flowrunner.ai/integrations/matrixflows
date_modified: 2026-09-04T14:52:04-07:00
---

# MatrixFlows

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

MatrixFlows is the AI knowledge enablement and collaboration platform. Agents read table schemas, create and update records with comments, attachments, and images, work the inbox, and react to record events in real time.

[Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 1 trigger · 23 actions · API key · available

[MatrixFlows website](https://matrixflows.com/) · [Platform Documentation](https://www.matrixflows.com/) · Capability data verified 2026-08-24

1.  On MatrixFlows Record Event fires when a record is created or updated in the workspace
2.  Get Record returns the record with its field definitions alongside its values, so the agent can read it without a second call
3.  Who Am I confirms the connection is scoped to the workspace the flow expects, since a wrong workspace answers like a bad token
4.  The agent decides whether the change is complete enough to act on or is missing the fields the downstream process needs
5.  Update Record writes the enrichment back, and Comment On Record leaves the reasoning in the record's own comment field
6.  The owning team is told what changed, with the record and the comment linked
7.  When the record duplicates something the agent cannot verify, a person confirms against the console before Delete Record is called

## What This Integration Enables

MatrixFlows models a workspace as tables of typed fields, which the interface calls collections, with records that carry comments, attachments, and images in named fields. That structure is what makes it usable by agents: Get Table returns the field keys, and every write addresses those keys rather than guessing at labels. FlowRunner agents read a table's schema, create and update records in bulk, attach files and images to the specific fields that hold them, download those attachments into FlowRunner file storage, read the workspace inbox, and manage webhooks. Every action is built and verified against the MatrixFlows Public API.

One design fact shapes every workflow built on this connector, and it is better stated up front than discovered later. MatrixFlows publishes a route to get one record by id and no route to list records. There is no polling path and no way to walk a table. The record event trigger, whose payload carries the record id on every delivery, is the supported way a workflow learns that a record exists. So this is an event driven knowledge base rather than a queryable one: it will tell an agent what changed, reliably and in real time, and it will not tell an agent what is there. Building on that honestly means the workflows that work best here are the ones that react, and the ones that would need a full inventory are the ones where FlowRunner's [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate does the work the API cannot.

### Without FlowRunner

**Knowledge goes stale silently**: A record written once is never revisited, and nothing signals that the world moved on

**Context lives beside the record**: Reasoning, files, and screenshots end up in chat threads rather than on the thing they describe

**Changes are noticed late**: Somebody spots the edit in a weekly review, days after the process that depended on it ran

### With FlowRunner

**Changes are the starting gun**: The record event drives the workflow, so enrichment happens at the moment the record moves

**Context lands on the record**: Comments, attachments, and images are written into the record's own fields where the next reader will find them

**Destructive edits have an owner**: The agent gathers the evidence, and a person confirms anything it cannot prove from the API alone

## Use Case Scenarios

### New knowledge arrives and gets finished

Somebody adds a record to the answers table, half filled in because they were mid conversation when they wrote it. The record event fires, and the agent calls Get Record with metadata included so it reads the field definitions and the values together. It fills the gaps it can source: the owning product area, the linked ticket in [Zendesk](https://flowrunner.ai/integrations/zendesk), the last time the underlying feature changed. Update Record writes those back to the field keys Get Table reported, and Comment On Record leaves a short note in the record's comment field saying what was inferred and from where. The person who started the record is told in [Slack](https://flowrunner.ai/integrations/slack) that it is ready for review. The half written record becomes a usable one without anyone reopening it.

### Support evidence attached where the answer lives

A support conversation produces a screenshot and a log file that explain a recurring problem better than any prose does. The agent creates the record with Create Records, then calls Upload Attachment for the log and Upload Image for the screenshot, naming the field each one belongs in, because MatrixFlows keeps images on a separate route from attachments and an image field will not accept an attachment upload. Later, when the same question comes back, another flow calls Download Attachments to pull those files into FlowRunner file storage and sends them on with the reply. Because the field key is part of the download path, a record with files in several fields needs one call per field, and the workflow is written that way rather than assuming a single fetch.

### Onboarding and offboarding the workspace itself

When people join or leave, the agent keeps the workspace membership in step with the HR system. New starters arrive in batches, so Create Users adds several at once, and Update User keeps details current. Leavers are removed with Delete User, but only after the offboarding flow has confirmed the departure against the source system, since the agent has no way to enumerate what a person authored and check what removing them affects. Where the workspace is one of several a team runs on the same token, the flow calls Who Am I first, because a wrong workspace answers with an authentication error rather than a not found, and that is the difference between a mistake caught in one call and an hour spent rotating a token that was never wrong.

## Human-in-Loop Highlight

Delete Record is where this connector's missing listing route stops being a curiosity and becomes the reason a person is needed. When the agent sees two records that look like the same answer written twice, it can pull both with Get Record and compare them field by field. What it cannot do is check the rest of the table, because MatrixFlows publishes no way to read it. The agent knows about the records the trigger has delivered to it. It cannot prove that the one it is about to delete is a duplicate rather than the only copy of something, and it cannot prove that nothing else points at it. So it stops and posts to the knowledge owner: "Two records in the FAQ table describe refund eligibility. Record A was updated yesterday and has two comments and an attachment. Record B is older, has no attachments, and its text is a subset of A. I cannot list this table, so I have not checked whether anything else references B. Confirm in the console which one survives, and I will move the comments across before deleting the other." The owner checks the one place that can answer it, and the deletion happens with a name against it.

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

23 actions

### Workspace and Users

6

-   **Who Am I** Returns the identity behind the token in this workspace. The cheapest confirmation that a connection reaches the right workspace, and the first call to make when an authentication error is ambiguous.
-   **List Users** Returns the people in a workspace.
-   **Create User** Adds one person to the workspace.
-   **Create Users** Adds several people to the workspace in one call, which is the shape a joiner batch from an HR system arrives in.
-   **Update User** Changes a workspace user's details.
-   **Delete User** Removes a person from the workspace. Worth pairing with a confirmed departure in the source system rather than running on a hunch.

### Tables

4

-   **List Tables** Returns the workspace's tables. A table is what the interface calls a collection, and its id is what every record operation needs.
-   **Get Table** Returns a table's metadata, including its fields and their keys. This is where a workflow discovers the field keys that Create Records and Update Record write to.
-   **Create Table** Creates a table with its fields.
-   **Update Table** Changes a table's definition. Field keys are what every write depends on, so a schema change reaches every workflow that touches the table.

### Records

5

-   **Get Record** Returns one record. Including metadata adds the field definitions alongside the values, which saves a Get Table call when a workflow needs to interpret them.
-   **Create Records** Creates records in a table, optionally returning the created row rather than only a status.
-   **Update Record** Changes a record, optionally returning the updated row. Without that, the response is a status and nothing else.
-   **Delete Record** Deletes a record. Because this API has no way to list a table, an agent cannot verify what else depends on the record it is removing, which is why this page's human gate sits here.
-   **Comment On Record** Adds a comment to a record. The comment goes into a named comment field, so the field has to be one the table actually has.

### Attachments

3

-   **Upload Attachment** Attaches a file to a record, into the attachment field named on the call. Get Table is where those field names come from.
-   **Upload Image** Attaches an image to a record. MatrixFlows keeps images on a separate route from attachments, so an image field will not take an attachment upload.
-   **Download Attachments** Downloads a record's attachments from one field into FlowRunner file storage. The field key is part of the path, so a record with files in several fields needs one call per field.

### Inbox

1

-   **List Inbox Conversations** Returns the workspace's inbox conversations, which is how a workflow reads what people are asking before deciding what the knowledge base is missing.

### Webhooks

4

-   **List Webhooks** Returns the webhooks attached to a workspace, including any this connector's trigger created.
-   **Attach Webhook** Registers a webhook on a workspace, for delivering events to a system other than FlowRunner.
-   **Update Webhook** Changes an attached webhook.
-   **Detach Webhook** Removes a webhook from a workspace, stopping its deliveries.

## Triggers

1 triggers

### Event Triggers

1

-   **On MatrixFlows Record Event** Fires when MatrixFlows reports a record event, with All Events covering created, updated, and deleted. Setting a content type narrows the subscription to one kind of content rather than the whole workspace, which is worth doing on a busy account. Since this API publishes no way to list records, the trigger's payload is the supported way a workflow learns a record id at all, which makes it the entry point for most flows built here rather than one option among several.

## Frequently Asked Questions

### What can FlowRunner do with MatrixFlows?

FlowRunner agents can run Who Am I, List Users, and Create User in MatrixFlows, plus 20 more actions.

### Does connecting MatrixFlows to FlowRunner require OAuth?

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

### Can MatrixFlows trigger a FlowRunner workflow automatically?

Yes. MatrixFlows supports 1 trigger that can start a FlowRunner workflow automatically.

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