FlowRunner
PricingContact
Theme
Start Free

Fusioo

Database

Fusioo is a collaborative online database organized as apps containing records, with discussions, files and users alongside the data. Agents search and write records, count and filter them, post discussions and comments, manage files and react to record changes through webhooks.

Verified 1 trigger 30 actions OAuth available
Fusioo website Platform Documentation Capability data verified 2026-08-27
On Record Change fires when a record is created, updated or deleted in a Fusioo App
Get Record returns the full field values behind the change
Get App maps field ids to labels, because Fusioo addresses fields by id and a body keyed on the visible column name writes nothing
Create Discussion raises the item as a thread on the record itself rather than in a separate tool
Create Comment adds the detail and mentions the owner using Fusioo's mention markup, which is what actually notifies them
Count Filtered Records reports how many other records share the same condition, so the thread carries scale as well as detail
The owner reads the thread on the record and decides what happens next

What This Integration Enables

Fusioo makes two choices most no-code databases do not. Deleting a record moves it to a trash that has its own read operations, so a deletion is a state you can inspect rather than an event you have to reconstruct. And discussions live on the record, so the argument about a number sits next to the number. FlowRunner agents use both. They search and write records, count a filtered set before paging through it because the account's hourly call budget is modest, audit the trash on a schedule, and open threads on records where the next person will read them.

The trigger completes the loop. On Record Change subscribes to creates, updates and deletes in an App, so a change in Fusioo can start a workflow somewhere else and a decision made somewhere else can come back as a comment on the record. That round trip is the point. FlowRunner's human-in-the-loop model works because the question reaches the person where they already work, and in Fusioo that place is the record.

Without FlowRunner

Conversation lives elsewhere The record says what changed, and the reason it changed sits in a chat thread nobody can find six months later
Deletions are opaque Something is gone, and reconstructing what it held means asking whoever removed it
Field ids guessed from labels A write keyed on the column name people see returns success and changes nothing

With FlowRunner

Conversation on the record Agents open a discussion and mention the owner where the data already is, so the decision and its evidence stay together
Deletions are auditable The trash has its own read operations, so an agent can list, search and inspect what was removed before anyone decides to restore it
Ids resolved at run time Get App supplies the current field ids before every write, so a schema change surfaces as a mapping step rather than a silent no-op

Use Case Scenarios

  • A record change that reaches the rest of the stack

    A project record moves to a billable status. On Record Change fires, the agent calls Get Record for the full values and Get App to resolve the field ids, then pushes the details onward: an invoice draft in QuickBooks Online, a row appended to the finance tracker in Google Sheets, and a short note into Slack for the account lead. Back in Fusioo, Create Discussion opens a thread on the same record recording what was raised and where, so the trail does not end at the boundary of the tool.

  • Reviewing what disappeared

    Once a week an agent calls Get Deleted Records for each App and Search Deleted Records for the categories that matter, then pulls anything unexpected with Get Deleted Record so the full field values are in front of a person. It builds a short report: what was removed, when, and what it held. Nothing is restored automatically, because restoring is done in the Fusioo interface. The value is that the review happens at all, and that it happens against records rather than against a log line.

  • Keeping the file library from rotting

    An agent inventories files with Get File and cross-references which ones are still referenced from record fields and comments. Orphans that nothing points at become a cleanup candidate list. Files that are still referenced never enter it. The list goes to the person who owns the App, with the reasoning attached, and Delete File runs only against what comes back approved.

Human-in-Loop Highlight

Fusioo's trash is generous about records and silent about files. Delete Record moves a record aside and leaves it readable through the deleted record operations. Delete File does not: it removes the file permanently, and every record field and comment that referenced it keeps the reference while the reference stops resolving. So the storage cleanup agent never deletes a file on its own arithmetic. It posts: "14 files in the Contracts App are not referenced by any current record field. 3 of them are referenced from comments on records deleted last quarter, which are still in the trash and could be restored. Delete all 14, delete only the 11, or hold?" The App owner picks. The agent then deletes exactly that set. The agent is better than a person at finding orphans across thousands of records. It is not the one that should decide which orphan is actually the last copy of something.

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

30 actions

Account

1
  • Ping Verifies that the configured credentials reach Fusioo. It is the vendor's recommended credential check and one of the few routes that is not rate limited, which makes it the right health check.

Apps

2
  • Get Apps Returns the Apps in the account. An App is Fusioo's table, and its id is what every record operation needs.
  • Get App Returns one App with its full field list, including every field's id, name and type. Call it before writing records, because Fusioo addresses fields by id.

Records

8
  • Get Records Returns the records in an App, sorted and paged. The plain listing.
  • Search Records Returns the records in an App that match a filter. Fusioo puts filtering on a separate route, so this is the read for anything beyond a full listing.
  • Get Record Returns one record by identifier with all of its field values.
  • Count Records Returns how many records an App holds. Used to size a job before paging, which matters against a modest hourly call budget.
  • Count Filtered Records Returns how many records match a filter without returning them. Run it with the same filter before Search Records to size the result set.
  • Create Record Creates a record in an App from field id and value pairs. Fields not supplied are left empty.
  • Update Record Updates a record, writing only the fields supplied and leaving the rest untouched.
  • Delete Record Moves a record to the Fusioo trash. It is not erased, and the deleted record operations can still read it.

Trash

3
  • Get Deleted Record Returns a trashed record with its field values intact. Used to inspect what a deletion removed before anyone decides to restore it.
  • Get Deleted Records Returns the trashed records of an App, sorted and paged. The read behind a deletion audit.
  • Search Deleted Records Returns trashed records matching a filter, using the same filter shape as Search Records.

Discussions and Comments

5
  • Create Discussion Starts a discussion thread on a record. This is how an agent raises something for a person to look at on the record itself rather than in a separate channel.
  • Get Discussions Returns the discussion threads on a record, paged.
  • Get Discussion Returns one discussion thread with its comments.
  • Delete Discussion Deletes a discussion thread and its comments from a record.
  • Create Comment Adds a comment to a discussion thread. Notifying someone requires Fusioo's mention markup rather than a plain name, and files can be attached by id.

Users

2
  • Get Users Returns the users in the account. Their ids are what a mention needs and what a link to user field expects.
  • Get User Returns one user by identifier, with their name, email and account type.

Files

4
  • Create File Uploads a file into Fusioo from a URL and returns its id. The upload alone attaches it to nothing.
  • Get File Returns a file's metadata: its name, size and upload date.
  • Download File Downloads a file's contents from Fusioo.
  • Delete File Permanently deletes a file. Records and comments referencing it keep the reference, but it no longer resolves.

Webhooks

5
  • Create Webhook Creates a webhook on one App and returns it with a signing secret. At least one change flag must be on, or the webhook fires for nothing.
  • Get Webhooks Returns the webhooks in the account with their URLs, Apps and event flags.
  • Get Webhook Returns one webhook by identifier.
  • Update Webhook Changes a webhook's URL or which record changes fire it.
  • Delete Webhook Permanently removes a webhook. Its signing secret goes with it, so recreating the subscription issues a new one.

Triggers

1 triggers

Event Triggers

1
  • On Record Change Fires when a record is created, updated or deleted in a Fusioo App. A subscription covers one App, so the workflow picks the App and then the change types it cares about, and at least one change type has to be selected or the subscription fires for nothing.

Frequently Asked Questions

What can FlowRunner do with Fusioo?

FlowRunner agents can run Ping, Get Apps, and Get App in Fusioo, plus 27 more actions.

Does connecting Fusioo to FlowRunner require OAuth?

Yes. Fusioo connects to FlowRunner with OAuth 2.0, so agents authenticate without handling raw credentials.

Can Fusioo trigger a FlowRunner workflow automatically?

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

Start building with Fusioo

Free plan, no card required. Connect in minutes.