Magentrix
CRMConnect 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.
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
With FlowRunner
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 and a summary posts to the partner channel in 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 moment that a generic entity API demands, because the platform gave the agent one verb for two different kinds of loss.
Agent Capabilities
17 actionsQuery 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.
Start building with Magentrix
$100 in credits. No card required. Connect in minutes.