--- title: "Magentrix Integration" description: "Connect AI agents to Magentrix, a partner relationship management and customer community platform. Agents read and write records across any Magentrix object, resolve schema metadata, and manage the files attached to them." url: https://flowrunner.ai/integrations/magentrix date_modified: 2026-08-11T09:36:14-07:00 --- # Magentrix [CRM](https://flowrunner.ai/integrations/category/crm-sales) Connect AI agents to Magentrix, a partner relationship management and customer community platform. Agents read and write records across any Magentrix object, resolve schema metadata, and manage the files attached to them. 17 actions · Session · available [Platform Documentation](https://help.magentrix.com/wikis/devguide) · Capability data verified 2026-08-11 1. A scheduled sync, a partner submission, or an upstream record change starts the run 2. Describe Entity returns the exact field names and types for the entity the flow is about to touch 3. Query Records runs a MEQL filter to find what already exists before anything is written 4. Get Entity List confirms the API Key user can actually see the entities the flow assumes 5. Upsert Record matches on an email or external ID so a repeat run enriches rather than duplicates 6. The partner manager is told what was created, what was matched, and what was skipped on permissions 7. A person confirms the selection before Delete Records runs, because the same call soft deletes some rows and permanently destroys others ## What This Integration Enables Magentrix is a partner relationship management and customer community platform, which means the people whose records live in it do not work for you. That is the whole premise, and it is why the platform enforces field level security, record sharing rules, and a role hierarchy on every single call. A partner sees their deals and not their competitor's. So when a flow queries Magentrix, the result is not "the data", it is "the data this API Key user is permitted to see", and a short result set is as likely to be a permissions answer as an absence of records. Building here means treating access control as a first-class part of the logic rather than an operational detail, and Get Entity List exists precisely so a flow can establish what it can reach before it draws a conclusion from what came back. The API itself is a generic, Salesforce style entity model, and the connector matches it rather than pretending to be a fixed CRM. Query Records, Get Record, and the List actions run MEQL, a `SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT` language, with a synchronous query returning up to 10000 records and Get Record returning only the fields you name, defaulting to `Id`. Create Record, Update Record, Upsert Record, and Delete Record work against any entity including Account, Contact, User, Case, and anything custom the tenant added, and their plural counterparts take arrays: upsert bulk stays under 1000 records and 20 MB, and Delete Records accepts up to 200 IDs per request where a bulk delete that partially fails returns HTTP 202 rather than an error. Describe Entities and Describe Entity resolve the schema at design time so a query is written against real field names. Each deployment lives at its own portal domain, and the API Key is exchanged at the token endpoint as an OAuth `refresh_token` for a short lived session ID that is sent as a Bearer token on every call, minted and cached automatically, with no user consent redirect involved. Upload Document takes a publicly reachable download URL that Magentrix fetches server side rather than a direct file upload, and Download Document streams the file into FlowRunner file storage and returns a URL to the stored copy. This extension defines no triggers, so nothing here listens for Magentrix events. Change detection is a scheduled MEQL query with a modified-date predicate and a stored high-water mark. ### Without FlowRunner **Field names are assumed**: A payload is written against a schema from another tenant and silently drops values **Permissions look like missing data**: A query returns fewer rows than expected and nobody can tell whether the records are absent or invisible **Partner records drift between systems**: The same account exists in two places with two answers, and reconciliation is a quarterly project ### With FlowRunner **Field names are read from the tenant**: Describe Entity supplies the authoritative names before a query or a write payload is built **Permissions are visible as permissions**: Get Entity List establishes what the API Key user can reach, so a short result is explained rather than mysterious **Partner records converge on one answer**: Upsert Record matches on an external ID, so repeat runs update the same row instead of adding another ## Use Case Scenarios ### Partner accounts and contacts that reconcile instead of accumulating A partner list lives in an internal system and a subset of it lives in the portal. On a schedule the agent calls Describe Entity on Account and Contact to confirm the field names in this tenant, because a Magentrix deployment is configured per customer and a query written against another tenant's schema fails in the least useful way. It then runs Query Records with a MEQL filter for records modified since the last run, joined in the flow against the internal source. Matches go through Upsert Record keyed on an external ID, which is the important choice: an upsert keyed on a stable external identifier makes the sync idempotent, so a run that half completed and got retried updates the same rows rather than creating a second copy of every partner. New records go through Create Records as an array. Anything the query could not see is reported as a permissions question rather than as a missing record, because Get Entity List has already told the flow what this API Key user can reach. ### A partner pipeline report that respects who is allowed to see it The partner team wants a weekly view of registered deals by partner. The agent runs Query Records with a MEQL statement selecting only the fields it needs, ordered and limited explicitly, then List Accounts and List Users to resolve the partner organisation and the owning user on each row. Because field level security applies to the API Key user, the report is built against a credential scoped to what that report is allowed to contain, rather than against an administrative key that would quietly widen the audience of a spreadsheet. The joined set lands in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) and a summary posts to the partner channel in [Slack](https://flowrunner.ai/integrations/slack). Nothing is written back, which makes this run safe to schedule daily. ### Agreements and proposals that reach the portal without an upload step A document generator renders a partner agreement or a proposal and publishes it at a URL. The agent calls Upload Document with that URL, and Magentrix fetches the bytes server side, which means the flow never needs to hold the file, only to make it reachable for the duration of the call. Going the other way, a partner submits a document into the portal and the agent calls Download Document, which streams the file into FlowRunner file storage and returns a URL to the stored copy, so a downstream extraction or approval step has something durable to work against. Query Records establishes which portal records have a document attached and which are still waiting, which is the check that turns a document pipeline into something reportable rather than something people ask about. ## Human-in-Loop Highlight Delete Records is the most dangerous action on this connector, and the reason is a single sentence in the vendor's own documentation: native Magentrix records are soft deleted into the recycle bin, and records that live in an external connected system are removed permanently. That is two entirely different levels of consequence behind one call, and the caller cannot tell which one it is getting from the request it is about to send. An ID is an ID. The flow that assembled the list from a MEQL query has no field in that result saying "this row is backed by an external system and will not come back". Compound that with the shape of the operation: Delete Records takes up to 200 IDs at a time, a query that feeds it can return up to 10000 rows, and a partial failure comes back as HTTP 202 rather than an error, so a batch that half succeeded looks like a batch that succeeded. An agent doing a cleanup here can destroy a set it cannot enumerate afterwards and will not be told it did. So the gate sits on the selection, not on the deletion mechanics. The agent runs the MEQL query, calls Describe Entities to establish which entities the matched IDs belong to, and posts to the partner operations owner: "The cleanup query matched 1,847 records for removal across three entities. 1,612 are Contact records on inactive partner accounts. 214 are Deal Registration records older than the retention window. 21 belong to an entity backed by an external connected system, listed here, and deletion of those is permanent rather than recoverable from the recycle bin. Deletes run 200 at a time and a partial failure returns 202, so a half-completed batch will not raise an error. Approve all three sets, approve the two recoverable sets and hold the 21, or hold everything and let me export the list first?" The owner answers once, and only the approved entities go into Delete Records, batched, with each response checked for the 202 that means the batch was not clean. This is the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) moment that a generic entity API demands, because the platform gave the agent one verb for two different kinds of loss. 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 17 actions ### Query and Read 5 - **Query Records** Runs a MEQL \`SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT\` statement against any entity. A synchronous query returns up to 10000 records, and results reflect the API Key user's field level security and sharing rules. - **Get Record** Retrieves a single record by ID, returning only the fields you name and defaulting to \`Id\`. Used to confirm state before a write rather than to pull a whole row. - **List Accounts** Returns accounts through MEQL. Used to resolve the partner organisation on a deal registration or a contact. - **List Contacts** Returns contacts through MEQL. Used to resolve the people attached to a partner account before an outreach or a sync step. - **List Users** Returns portal users through MEQL. Used to resolve owners and to attach a real name to a routing decision. ### Writes 4 - **Create Record** Creates a single record in any entity. Used when an upstream signal introduces something the portal does not have. - **Update Record** Updates a single record. Writable fields depend on the API Key user's field level security, so a silently unchanged field is usually a permissions answer. - **Upsert Record** Creates or updates a record matched on an email or external ID. This is what makes a repeated sync idempotent instead of duplicative. - **Delete Record** Deletes a single record. Native records go to the recycle bin, while records that live in an external connected system are removed permanently, so this runs on an approved selection. ### Bulk Operations 3 - **Create Records** Creates an array of records in one call. Used to land an imported list without a per-row loop. - **Update Records** Updates an array of records in one call. Used for field corrections applied across a set. - **Delete Records** Deletes up to 200 IDs per request. A bulk delete that partially fails returns HTTP 202 rather than an error, so a flow must inspect the response instead of trusting the absence of an exception. ### Metadata 3 - **Get Entity List** Returns only the entities the API Key user can access. This is the preflight that separates "no records" from "no permission" before a flow draws a conclusion from an empty result. - **Describe Entities** Returns metadata across entities. Used at design time to map the tenant's data model before a query or a payload is built. - **Describe Entity** Returns a single entity's fields, types, and metadata. Because each deployment is configured per customer, this is the authoritative source for field names in a MEQL statement or a write. ### Documents 2 - **Upload Document** Attaches a document by supplying a publicly reachable download URL that Magentrix fetches server side. The flow makes the file reachable rather than holding and posting the bytes itself. - **Download Document** Streams a portal document into FlowRunner file storage and returns a URL to the stored copy, so downstream extraction or approval steps have something durable to work against. ## Frequently Asked Questions ### What can FlowRunner do with Magentrix? FlowRunner agents can run Query Records, Get Record, and Create Record in Magentrix, plus 14 more actions. ### Does connecting Magentrix to FlowRunner require OAuth? No. Magentrix connects to FlowRunner with session-based authentication, no OAuth flow required. ### Can Magentrix trigger a FlowRunner workflow automatically? Magentrix doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Magentrix?** This integration exposes Magentrix 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/magentrix. Site index: https://flowrunner.ai/llms.txt