Infor M3
ERPConnect AI agents to Infor M3, a tenant-hosted enterprise ERP reached through the Infor ION API gateway. Agents look up customers, items, warehouses, and company data through named read actions, and run any M3 program through a generic MI transaction when a write is needed.
What This Integration Enables
Infor M3 is a tenant-hosted enterprise ERP, and the honest description of this connector is that it is a disciplined bridge to the M3 API transaction surface through the Infor ION API gateway, not a curated object model laid over it. That is the right shape for M3. Company numbers, division codes, warehouse codes and every field enum are configured per tenant, so there is no universal lookup, and a connector that shipped hardcoded dropdowns would be shipping another tenant's configuration. This one ships none. Instead it gives agents Execute MI Transaction, a universal action that calls any M3 program and transaction by name and passes MI field inputs as a key value object using the uppercase M3 field codes such as CUNO, ITNO and WHLO, with the company number CONO passed through its own dedicated parameter. Matrix parameters are supported the way M3 expects them, appended to the transaction path with semicolons rather than sent as query parameters: ;maxrecs=N caps how many records a list transaction returns, ;returncols=COL1,COL2 limits the output to specific fields, and ;metadata=true includes field metadata with the records. Responses come back exactly as M3 sends them, as an MvxMIResponse records structure, because the fields returned depend entirely on the transaction and the tenant and reshaping them would be inventing a schema.
Be precise about reads and writes here, because the two are not symmetrical. The named convenience actions are all read-only. List Customers By Number, List Customers By Name, Get Customer Basic Data, List Items, Get Item Basic Data, Get Item Warehouse Data, List Companies, List Divisions, List Warehouses and Get Warehouse are Lst and Get transactions and they change nothing. To create, change or delete M3 data you use Execute MI Transaction with the appropriate Add*, Chg* or Del* transaction, which is why that single action uses a write-style route. So the practical description of this connector is: named, safe reads over customers, items, companies, divisions and warehouses, plus one general purpose door to everything else M3 can do, including the destructive parts. Get Transaction Metadata exists to make that door usable: it uses ;metadata=true together with ;maxrecs=0, so it returns the field metadata for a transaction, type, length and description, while reading no business records at all. Discovering the field codes of an unfamiliar transaction is a read that touches no data.
On events, this service has no triggers. M3 change notifications are delivered through Infor ION events and document flows rather than a per-integration webhook subscription API, so there is no native trigger here and nothing in this connector creates one. Change detection is a scheduled poll against the list transactions, capped with ;maxrecs and narrowed with ;returncols so a nightly reconciliation reads columns rather than whole records. One caveat is worth stating plainly, because it changes how you should adopt this. The m3api-rest contract used here is fully public, transcribed from the Infor ION API SDK and the M3 API references on docs.infor.com, but token endpoints and data hosts are per tenant, so the preset transaction codes shipped here, for example MNS150MI/LstCompanies and MMS060MI/GetWarehouse, are the documented canonical names rather than names confirmed against a live tenant. If a preset differs in your M3 version, Execute MI Transaction makes the same call generically.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Master data read out of the ERP instead of exported from it
A sales or finance team needs the M3 customer master somewhere they can work with, and the current answer is a monthly export that is stale by the second week. On a schedule the agent calls List Customers By Number with ;maxrecs set to a sensible cap and ;returncols narrowed to the fields the downstream sheet actually uses, then Get Customer Basic Data on the accounts that changed since the last run. The rows land in Google Sheets and the deltas are posted to the account owners through Slack. Because responses come back as the raw MvxMIResponse records structure, the flow maps NameValue pairs explicitly rather than assuming a shape, which is what keeps it working when a tenant returns a field the last run did not. Nothing is written to M3, so this is a read that can run every night without a conversation.
Stock answered in chat without an M3 login
Warehouse and customer service staff need item availability, and most of them do not have an M3 seat. A question arrives in a shared channel through Slack. The agent parses the item reference, calls List Items to resolve it to a real ITNO, then Get Item Warehouse Data for the warehouse in question, having first resolved the warehouse code through List Warehouses because WHLO values are configured per tenant and cannot be assumed. It answers in the channel with the item description, the warehouse and the figures M3 returned, and says which warehouse it read rather than presenting one number as the answer. Get Warehouse fills in the warehouse detail where the question is about a site rather than a part. The whole exchange is read-only, which is what makes it appropriate to expose to a channel full of people.
A new ERP customer created under supervision
A deal closes in the CRM and the customer needs to exist in M3 before anything can be ordered. The agent gathers the customer detail, then calls Get Transaction Metadata against the customer program's add transaction to read the exact field codes, types and lengths this tenant expects, rather than sending field names carried over from a previous implementation. It runs List Companies and List Divisions to confirm the CONO and DIVI values that exist here, and List Customers By Name to check that the customer is not already on file under a slightly different spelling. It then assembles the Execute MI Transaction call and stops, presenting the program, the transaction, the company number and every field value to the ERP owner for approval. On approval the transaction runs and the raw response is written back to the CRM record and mailed to the account owner through Gmail, so the person who asked for the customer knows the ERP record is ready and which transaction created it.
Human-in-Loop Highlight
Execute MI Transaction is the gate, and it is the gate because of what the action cannot tell you. Every named action in this connector is read-only, so the entire write surface of Infor M3 arrives through this one call, where the difference between reading a customer and deleting one is a four letter difference in the transaction name passed as a string. GetBasicData and DltBasicData sit on the same program, take the same company number, and are typed into the same field. The connector cannot classify them for you, because M3 transaction naming is a convention rather than a contract and the set is per version. Two more things compound it. Company numbers, division codes and warehouse codes are configured per tenant with no universal lookup, so a CONO carried in from a test environment is a valid number in the wrong company rather than an error. And the preset transaction codes shipped here are documented canonical names transcribed from Infor references rather than names confirmed against a live tenant, so a preset that differs in your M3 version fails at the point of use rather than at the point of configuration. So the agent never writes to the ERP on its own recognisance. It assembles the call, proves the read side first, and asks. It posts to the ERP owner: "Ready to create 6 customers in M3 from the closed deals. Program CRS610MI, transaction AddBasicData, company CONO=100, division DIVI=A01, both confirmed present through List Companies and List Divisions on this tenant. Get Transaction Metadata returned 14 fields for this transaction; I am sending 9 and leaving 5 empty, listed below with their types and lengths. List Customers By Name found a near match for two of the six, NORDIC MASKIN AB against an existing NORDIC MASKIN A B, so those two may be the same account under a different spelling. Approve the 4 clean ones, and tell me whether the two near matches are new customers or existing ones I should read instead of create." The ERP owner answers once. This is the human-in-the-loop moment on an enterprise ERP: an agent can prove the transaction exists and the company number is valid, and only a person who owns the M3 configuration can say whether the write is the right one to make.
Agent Capabilities
12 actionsCore
2- Execute MI Transaction Calls any M3 program and transaction by name, passing MI field inputs as a key value object using uppercase M3 field codes. Supports the matrix parameters M3 expects, `;maxrecs=N` to cap returned records, `;returncols=COL1,COL2` to limit output fields and `;metadata=true` to include field metadata. This is the only write path in the connector, covering `Add*`, `Chg*` and `Del*` transactions, which is why it runs behind an approval.
- Get Transaction Metadata Returns the field metadata for a transaction, including type, length and description, using `;metadata=true` together with `;maxrecs=0` so it reads no business records at all. Run this before wiring an unfamiliar transaction into a flow rather than assuming field codes from a previous project.
Customers
3- List Customers By Number Lists customers by customer number. Read-only. The standing read behind a customer master synchronisation.
- List Customers By Name Lists customers by name. Read-only. Used as the near-duplicate check before a create transaction is proposed.
- Get Customer Basic Data Returns the basic data record for a single customer. Read-only.
Items
3- List Items Lists items from the item master. Read-only. Resolves a loose item reference to a real `ITNO` before anything downstream uses it.
- Get Item Basic Data Returns the basic data record for a single item. Read-only.
- Get Item Warehouse Data Returns item data for a specific warehouse, which is where availability questions are actually answered. Read-only, and it needs a `WHLO` resolved from this tenant rather than assumed.
Company Data
2- List Companies Lists the companies configured on this tenant, so a `CONO` is confirmed to exist before it is sent. Read-only.
- List Divisions Lists the divisions configured on this tenant, returning the `DIVI` codes in use. Read-only.
Warehouses
2- List Warehouses Lists the warehouses configured on this tenant, returning the `WHLO` codes that exist here. Read-only, and the reason a stock lookup names the warehouse it read.
- Get Warehouse Returns the detail for a single warehouse. Read-only.
Frequently Asked Questions
What can FlowRunner do with Infor M3?
FlowRunner agents can run Execute MI Transaction, Get Transaction Metadata, and List Customers By Number in Infor M3, plus 9 more actions.
Does connecting Infor M3 to FlowRunner require OAuth?
Infor M3 uses a custom authentication method to connect to FlowRunner.
Can Infor M3 trigger a FlowRunner workflow automatically?
Infor M3 doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Infor M3
$100 in credits. No card required. Connect in minutes.