Axelor
ERPConnect AI agents to an Axelor Open Suite instance, the open source ERP and CRM platform. Agents read and write records across sales, invoicing, projects, and partners, invoke Axelor actions, and inspect model metadata at runtime.
What This Integration Enables
Axelor made a decision that most ERP vendors did not: every domain object goes through the same door. Partners, leads, sale orders, invoices, projects, and whatever custom model your operator added last quarter are all read and written through one generic REST service addressed by the object's fully qualified name. That is why this connector is built the way it is. The Records layer works against any model at all, with find, advanced search, read, create, update, mass update, copy, delete, and version verification. On top of it sit typed actions that pre-select the model for the objects most flows need. The typed layer is a convenience, not the boundary: List Sale Orders, List Purchase Orders, and List Invoices read those documents with the right filters already exposed, and writes to those same objects go through Create Record and Update Record with field names resolved from Get Model Fields. That distinction matters when you are scoping a flow, so it is worth stating plainly rather than leaving it to be discovered.
Three facts about Axelor decide whether a flow works, and none of them are optional reading. First, this is self-hosted software, so there is no vendor address; you supply the root URL of your own instance and every service is reached under its /ws prefix. Get Application Info is served without authentication, which makes it the fastest way to separate a wrong URL from a wrong credential. Second, Axelor answers HTTP 200 even when the operation failed, marking the failure with a negative status in the envelope. This connector inspects that field on every call and raises a real error, so a rejected save surfaces as a failed step rather than a silent success that a downstream branch happily builds on. Third, every record carries a version, and Update Record, Delete Record, and Delete Records In Bulk all require the current one; if the record moved since you read it, the write is rejected instead of overwriting the newer data. That is optimistic locking working in your favour, and it is the reason a long-running flow re-reads immediately before it writes. Axelor Open Platform publishes no webhook subscription API, so this connector ships no triggers and change detection is a scheduled Search Records with a criterion on updatedOn or createdOn, sorted by -updatedOn, keeping the newest timestamp you have seen between runs. Both fields exist on every model that extends the auditable base entity. Agents do the reading and the writing. The bulk write that no version check will save you from is where human-in-the-loop orchestration belongs.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Data hygiene that shows its work before it does any
An operator wants every partner in a stale territory reclassified. The agent starts by calling List Models and Get Model Fields, because an Axelor deployment's field set depends on which Open Suite modules are installed and on whatever custom fields the operator added, and guessing a field name here produces a validation error at best. It then runs Search Records with the exact Domain Filter the update will use, for example a JPQL clause on self. with named parameters supplied through Domain Context, and returns the matched count along with a readable sample. Update Records In Mass refuses to run without a Domain Filter or at least one criterion, which is both the platform's own guard and an explicit one here, but a filter that is valid is not the same as a filter that is correct. The preview goes to the ERP owner in Slack before anything is written, and the reversible alternative stays on the table: setting archived to true through Update Record hides records from searches without destroying them, and archived exists on every Axelor object because it is defined on the platform's base model.
Receivables that chase themselves as far as a person
On a schedule the agent calls List Invoices with Document Type set to Customer Sale, because one Axelor Invoice object covers customer invoices, supplier invoices, and both kinds of credit note, and a query without that filter mixes sales with purchasing. It narrows to invoices still outstanding past their due date, then calls List Partners to resolve each customer and read whether they are flagged as a customer, a supplier, or both, since a single partner record carries a boolean flag per role. The overdue balances group by account owner and post as direct messages in Slack, while the full ledger view appends to a receivables sheet in Google Sheets for the controller. Nothing in this run writes to Axelor. The agent's job here is to make sure the right person sees the right number on the right morning, not to decide who gets chased.
An agent that can answer questions about an instance nobody mapped in advance
A team lead asks, in a Flow conversation, how many confirmed sale orders are open for a given customer this quarter. The agent has no hardcoded schema to fall back on, so it chains List Models to find the object, Get Model Fields to learn the field names and types that this instance really has, and Search Records with a Domain Filter to fetch exactly the rows that answer the question. Where the answer needs a business operation rather than a read, Execute Action invokes Axelor's own logic by XML action name or fully.qualified.ControllerClass:methodName, because confirming an order or recomputing totals lives in the application rather than in the REST layer. That is also where the conversation stops and a person takes over. Confirming a sale order or ventilating an invoice moves a document into a state it does not freely come back from, and a ventilated invoice is posted to the ledger. The agent assembles the record, the action name, and the context, and the finance owner presses go.
Human-in-Loop Highlight
Update Records In Mass is the operation to gate, and Axelor's own documentation says why in one line: it applies one set of values to every matched record in a single transaction, with no per record confirmation and no undo. Everything else in this connector protects you. Update Record demands the version it read and refuses to overwrite a record that moved. Delete Record does the same. The mass update does neither, because it never reads the individual records at all; it takes a filter and a value map and commits. The failure that actually happens is not a malicious one, it is an ordinary bad filter. A JPQL clause with a like pattern one wildcard too wide, or a criteria group whose nested or was meant to be an and, matches nine thousand partners instead of ninety, and Axelor does exactly what it was asked. So the agent inverts the order and treats the filter as the thing under review rather than the values. Before any mass write it runs Search Records with the identical Domain Filter and Domain Context, reads back the total from the response envelope, and pulls a sample of matched records with the fields the update would change. Then it posts to the ERP owner: "Reclassifying partners on filter self.partnerCategory.id = :cat and self.updatedOn < :cutoff. That filter matches 2,847 records, not the 120 the request implied. 11 of them are flagged as suppliers as well as customers, so the change would move them out of purchasing screens too. Update Records In Mass is one transaction with no per record confirmation and no undo. Setting archived to true through Update Record is the reversible alternative. Do you want the mass update, the archive, or a narrower filter?" The owner answers, and the agent writes only what was released. Delete Record and Delete Records In Bulk sit behind the same gate for the more obvious reason, and Execute Action joins them whenever the named action ventilates an invoice or confirms an order, because posting to the ledger is not an edit you take back. This is the digital andon cord placed at the one write in the connector that no version number can protect.
Agent Capabilities
31 actionsRecords
11- Find Records Returns a page of records of any Axelor domain model, addressed by fully qualified name such as `com.axelor.apps.base.db.Partner`. Accepts pagination only, with Axelor's own default limit of 40. The envelope carries the matched count in `total`.
- Search Records Runs an advanced search against any model, with field selection, multi field sorting where a leading minus sign means descending, a JPQL where clause through Domain Filter, and structured criteria combined with Match All or Match Any. Use it as the preview for any bulk write.
- Read Record Reads a single record by numeric id and returns its full default field set, including the version number that Update Record and Delete Record require.
- Fetch Record Fields Reads a single record but returns only the fields you ask for, optionally expanding many to one relations inline through the Related map. The right choice when a record has a wide field set and the flow needs three values from it.
- Create Record Creates a record of any model from a field map. Axelor uses PUT on the collection URL for creation. Many to one relations are written as nested objects holding the target id, for example `{"partner":{"id":42}}`.
- Update Record Updates a record of any model, using POST on the record URL. The current version is required and checked, so a record modified since it was read is rejected rather than overwritten.
- Update Records In Mass Applies the same field values to every record matched by a Domain Filter or criteria list, in one transaction with no per record confirmation and no undo. It refuses to run without a selection criterion. Validate the selection with Search Records first, and keep it behind a person.
- Delete Record Deletes a single record. The current version is required so a record that moved is not silently removed. Permanent.
- Delete Records In Bulk Deletes several records of one model in a single call, each entry carrying its id and current version. Permanent.
- Copy Record Returns a duplicate built by the model's own copy logic, so unique fields and non copyable relations are handled the way the application handles them. The copy comes back unsaved with no id; pass it to Create Record to persist it.
- Verify Record Version Checks whether a version number you hold is still current, answering with success when it matches and a validation error when the record has moved. Use it in a long running flow to detect a conflicting change without attempting the write.
Metadata
3- List Models Returns the fully qualified names of every domain model this instance exposes. Because Axelor is self hosted and extensible, that list differs between deployments, so discovery beats assumption.
- Get Model Fields Returns a model's field definitions with name, data type, and whether the field is required. This is how an agent learns the writable field names on an instance that has custom fields the connector has never seen.
- Get Application Info Returns the instance's public application information and is served without authentication. Call it first when a connection fails: a good answer means the Instance URL is right and the credential is the problem.
Actions
1- Execute Action Runs one or more Axelor actions against a record context, given an XML action name or a `fully.qualified.ControllerClass:methodName` reference. This is how business logic such as confirming a sale order or recomputing totals is invoked, since that logic lives in the application rather than in the REST layer. Action names are specific to the modules installed on your instance.
Collaboration
2- Post Record Message Posts a message onto a record's activity stream, the same feed the Axelor form shows. Followers are notified according to the instance's messaging configuration, so this is how a flow leaves an audit note where a human will actually read it.
- Get Record Followers Returns the users following a record's activity stream. Useful for checking who an update would notify before posting one.
Partners
2- List Partners Lists partner records, the shared object covering customers, suppliers, prospects, contacts, and employees. A partner carries a boolean flag per role, so one record can hold several at once. Filter by name, by roles, and by company or individual.
- Create Partner Creates a partner. Only the name is mandatory. Set the role flags deliberately, because a partner with no role is not offered in sales or purchasing screens. Extra Fields merges custom and module specific fields into the record.
CRM
4- List Leads Lists CRM leads, filtered by name, status, and whether the lead has already been converted. Lead statuses are configurable records on your instance rather than a fixed enumeration.
- Create Lead Creates a CRM lead, where the mandatory name holds the contact's last name and Enterprise Name records the organization. Status, owner, and team decide where it appears in the pipeline.
- List Opportunities Lists CRM opportunities filtered by name, partner, and status, with amounts returned in the opportunity's own currency.
- Create Opportunity Creates an opportunity. Link it to a partner to have it appear on that customer's record, and set a currency when the amount is not in the company default. Probability is a percentage between 0 and 100.
Products
2- List Products Lists products from the shared catalog covering both stockable goods and services, filtered by partial name or code match, product type, and the sellable and purchasable flags.
- Create Product Creates a catalog product. Product Type decides whether the item is stockable and therefore participates in stock movements. Set the sellable and purchasable flags so it appears where it should.
Sales
2- List Sale Orders Lists sale orders, the one object that covers both quotations and confirmed orders, with the status deciding which it currently is. Filter by customer, status, and order date range.
- List Purchase Orders Lists purchase orders raised against suppliers, filtered by supplier partner and order date range. Status values come from the purchasing module of your instance, so filter on them through Search Records when you need a status condition.
Invoicing
1- List Invoices Lists invoices. One Axelor Invoice object covers customer invoices, supplier invoices, and both kinds of credit note, so set Document Type or the query mixes sales with purchasing. Status runs Draft, Validated, Ventilated, and Canceled, and a ventilated invoice is posted to the ledger and generally no longer freely editable.
Projects
3- List Projects Lists projects filtered by partial name or code, client partner, and status. Project statuses are configurable records on your instance.
- List Project Tasks Lists project tasks filtered by project, assignee, status, and deadline range. Task Type distinguishes ordinary tasks from tasks raised as tickets.
- Create Project Task Creates a task on a project. Only the name is mandatory, but a task without a project does not appear in project views, so set Project ID in almost every case. Extra Fields is how per project custom task fields get populated.
Frequently Asked Questions
What can FlowRunner do with Axelor?
FlowRunner agents can run Find Records, Search Records, and Read Record in Axelor, plus 28 more actions.
Does connecting Axelor to FlowRunner require OAuth?
No. Axelor connects to FlowRunner with an API key, no OAuth flow required.
Can Axelor trigger a FlowRunner workflow automatically?
Axelor doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Axelor
$100 in credits. No card required. Connect in minutes.