1CRM
CRMConnect AI agents to a 1CRM instance, a small business CRM and order management suite. Agents create accounts, contacts, quotes, and invoices, read and write any module through generic record operations, link related records, and upload files.
What This Integration Enables
1CRM is built for the company that never wanted two systems. The CRM and the order book are the same database, so a quote, an invoice, a sales order, and a payment sit next to the account they belong to rather than in a finance tool that syncs overnight. That decision shapes the connectors surface in a specific way: because 1CRM carries a SugarCRM lineage generic data model, this integration does not ship one action per object. It ships one consistent set of record actions addressed by module bean name, so Account, Contact, Lead, Opportunity, Case, Task, Quote, Invoice, SalesOrder, Payment, Note, Project, and ProductCatalog are reached the same way, and so is a custom module the business added last quarter. Bean names are singular rather than the plural label the interface shows, which is the first thing to get right, and Get Module Metadata exists so an agent can confirm the field and filter names on this instance instead of assuming them.
The part that changes how you design a flow is that order documents are composite. Create Invoice and Create Quote write the header only. Line groups and product lines are separate modules, InvoiceLineGroup and InvoiceLine for an invoice, QuoteLineGroup and QuoteLine for a quote, created with Create Record and linked through their *_id fields, with taxes and discounts carried by the *Adjustment modules and a product line pointing at a catalog entry through related_type: "ProductCatalog" and related_id. Building a document is therefore several calls that either all land or leave something half made, which is exactly the kind of boundary worth putting a person on. Elsewhere the details are straightforward. List actions return { records: [...], total_results: N } and page with offset and limit, Get Record returns { record: {...} }, Create Record returns { id }, and updates, deletes, and relationship changes return { result: true }. Delete Record is a soft delete that marks the record deleted in 1CRM rather than erasing it. Upload File returns a temporary file id that must be used as the value of an image or file_ref field, for example the filename field of a Note, before it expires, and Download File puts the attachment into FlowRunner file storage. Authentication is HTTP Basic over HTTPS against your own instance host, cloud or self hosted, and it is worth knowing that 1CRM disables Basic authentication for the API by default, so an administrator has to enable it for the account first. This connector ships no triggers and 1CRM exposes no webhook registration through it, so change detection is a scheduled poll on List Records with a filter, not an event subscription. A flow designed on the assumption that 1CRM will call FlowRunner when something moves will simply never fire.
Without FlowRunner
With FlowRunner
Use Case Scenarios
An order that becomes a complete invoice rather than a header
A confirmed order lands from a storefront or a spreadsheet in Google Sheets. The agent calls Get Module Metadata for Invoice and InvoiceLine to confirm the field names on this instance, then List Records on Account to resolve the customer and on ProductCatalog to resolve every ordered SKU to a real catalog id. Only once every line has an id does it write anything. Create Invoice opens the header and returns its id, Create Record builds the InvoiceLineGroup against that header, and each InvoiceLine is created with related_type: "ProductCatalog" and the resolved related_id so the line prices from the catalog rather than from whatever number the source file carried. Taxes and discounts go in through the *Adjustment modules. Upload File pushes the signed order confirmation and its temporary id is consumed immediately by a Note create, because that id expires. Any SKU that did not resolve does not become a zero priced line, it goes to the gate below.
A relationship view assembled from the links that hold it
An account manager wants to know what is actually attached to an account before a renewal call. The agent calls Get Record for the account by bean name, then Get Related Records through the relationship links to pull its contacts, its open cases, its quotes, and its unpaid invoices, paging with offset and limit rather than fetching the module. Get Calendar Events over the coming fortnight shows which meetings and calls are already booked against the account, and Get Audit Log shows what changed on the record and who changed it, which is the difference between a summary and a story. The joined view posts to the account owner in Slack. Nothing is written in this run, which is why it can be scheduled daily without an approval attached to it.
A custom module kept in step without a custom integration
Most 1CRM accounts grow a module the vendor never shipped, a service agreement, a site survey, an equipment register. Because records are addressed by bean name, the agent works against that module with the same List Records, Get Record, Create Record, and Update Record it uses for Account, and calls Get Module Metadata first so the field and filter names come from the instance rather than from a developer's memory. Add Related Records and Remove Related Record maintain the links between that module and the standard ones, so a site survey stays attached to the account it belongs to. Get Reports pulls the saved reports the team already trusts, and the run ends with a digest by Brevo rather than a new dashboard nobody asked for.
Human-in-Loop Highlight
The dangerous operation in 1CRM is not Delete Record, because that is a soft delete that marks the record deleted rather than removing it. It is Create Invoice, and the reason is that Create Invoice does not create an invoice. It creates a header. The lines are separate module records built afterwards with Create Record and linked through their *_id fields, and a product line only prices correctly when it carries related_type: "ProductCatalog" and a related_id that resolves to a real catalog entry. Nothing in that sequence is transactional. If the SKU on line four does not resolve, the flow has already written a numbered invoice header, a line group, and three lines, and what sits in 1CRM is a document that looks complete in a list view and is wrong in the total. It will be read by whoever chases the payment. So the agent resolves before it writes, and stops on the residue. It runs List Records against ProductCatalog for every line on the order, and posts to the order owner: "Order 44119 for Northbridge Facilities, 11 lines, 132,400 total in the source. 9 lines resolved to a catalog product. 2 did not: SVC-ONSITE-4H matches nothing, and PNL-450W matches two catalog entries with different prices, 214.00 and 229.00. If I write this now the invoice header posts with 9 lines and a total of 118,900, which will not match the order the customer signed. Map the 2 lines, create the missing catalog product first, or hold the invoice?" The owner answers once. Only then does Create Invoice run, and the whole composite is built against ids a person confirmed. This is the human-in-the-loop moment on a CRM where the invoice is assembled rather than posted, and it exists because an agent can see that a SKU failed to resolve while only a person can decide what it was supposed to be.
Agent Capabilities
21 actionsRecords
5- List Records Returns records from any module addressed by its singular bean name, paging with `offset` and `limit` and returning `{ records: [...], total_results: N }`. This is the scheduled read that stands in for the events this connector does not have.
- Get Record Retrieves a single record from any module, returning `{ record: {...} }` with a `_display` label field. Used to confirm current state before an update is composed.
- Create Record Creates a record in any module, including custom modules, and returns `{ id }`. This is also how the line groups, product lines, and adjustment records behind a quote or invoice are built.
- Update Record Updates a record in any module by id and returns `{ result: true }`. Field names should be confirmed through Get Module Metadata rather than assumed from the interface labels.
- Delete Record Marks a record deleted in 1CRM. A soft delete rather than a permanent erase, which is why the gate on this connector sits on document assembly rather than on deletion.
Relationships
3- Get Related Records Follows a relationship link to pull the records on the other side of it, for example an account's contacts or a project's tasks, paging with `offset` and `limit`.
- Add Related Records Links records across a relationship, which is how a custom module record stays attached to the standard record it belongs to.
- Remove Related Record Removes a single relationship link without deleting either record.
Order documents
2- Create Invoice Creates the invoice header only. Line groups, product lines, taxes, and discounts are separate module records created with Create Record and linked through their `*_id` fields, so this action is the first call in a composite rather than the whole document.
- Create Quote Creates the quote header only, with `QuoteLineGroup` and `QuoteLine` records built afterwards the same way. Used when a resolved opportunity should become a priced document.
Convenience records
2- Create Account Creates an account without addressing the module generically. Used at the top of an import where the customer does not yet exist.
- Create Contact Creates a contact and links it to its account. Used alongside Create Account when a new relationship arrives complete.
Metadata and audit
5- Get Module Metadata Returns the available fields and filters for a module on this instance. Used before any create or update so field names come from the running system rather than from documentation.
- Get Audit Log Returns the audit history for records, showing what changed and when. Read only, and the action that turns a record summary into an account history.
- Get Reports Returns the reports defined in 1CRM, so a flow can use the numbers the team already agrees on instead of recalculating them.
- Get Current User Returns the user the connection authenticates as, which is worth checking because Basic authentication for the 1CRM API is off by default and enabled per account by an administrator.
- Get Server Version Returns the 1CRM version the instance is running, useful when a flow has to behave differently across cloud and self hosted deployments.
Calendar
1- Get Calendar Events Returns meetings, calls, and tasks within a date range. Read only, used to see what is already booked against an account before a flow proposes anything. Calendar entries themselves are written through Create Record against the `Meeting`, `Call`, or `Task` bean.
Files
3- Upload File Uploads a file and returns a temporary file id. That id has to be consumed as the value of an `image` or `file_ref` field, for example the `filename` field of a Note, within the same run before it expires.
- Download File Retrieves an attachment from a 1CRM Note or Document, stores it in FlowRunner file storage, and returns a URL.
- Get File Info Returns metadata about a stored file without transferring it, used to check what is attached before deciding whether to fetch it.
Frequently Asked Questions
What can FlowRunner do with 1CRM?
FlowRunner agents can run List Records, Get Record, and Create Record in 1CRM, plus 18 more actions.
Does connecting 1CRM to FlowRunner require OAuth?
No. 1CRM connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can 1CRM trigger a FlowRunner workflow automatically?
1CRM doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with 1CRM
$100 in credits. No card required. Connect in minutes.