coreBOS
ERPConnect AI agents to a self-hosted coreBOS instance, the open source ERP and CRM fork of Vtiger. Agents read and write any module record, resolve relationships between them, and inspect module metadata to work against a customized schema.
What This Integration Enables
coreBOS is an open source business application framework and a fork of Vtiger, and the whole reason a company runs it is that they changed it. Modules, fields, picklist values, and relationships are instance defined, which means an integration that ships a fixed schema is wrong on arrival for most deployments. This connector takes the opposite approach and is module driven all the way down. List Modules and Describe Module report what your instance actually has, including custom modules nobody outside your building has heard of. Run VTQL Query, List Records, Search Records, and Count Records read against any of them. Create Record, Update Record, Revise Record, Delete Record, and Mass Create Records write to any of them. Get Related Records and Set Relation handle the relationships between them. Fourteen actions cover Accounts, Contacts, Leads, Potentials, HelpDesk, Products, and whatever else your operator defined, without a new integration having to be built each time the business changes shape.
Four behaviors decide whether a flow works here, and none of them are guessable. First, the connection: set the Instance URL to the base of your installation with no trailing /webservice.php, since all calls go to <Instance URL>/webservice.php. Authentication uses a coreBOS Username and that user's Access Key, found under My Preferences and distinct from the account password, and the connector performs the coreBOS challenge and login handshake internally, requesting a token, sending md5(token + accessKey), and caching the returned session for the invocation with a single automatic re-authentication if it expires. Second, record ids are composite. A coreBOS webservice id takes the form moduleId x recordId, for example 11x24, not the plain numeric id shown in the user interface, so ids come from List Records, Search Records, or a query rather than from a browser tab. Third, the webservice answers HTTP 200 even when the operation logically failed, carrying a { success:false, error } envelope; this connector inspects that and raises the coreBOS error, so a failed write surfaces as a failed step rather than a success a downstream branch builds on. Fourth, and most important for anything that writes, Update Record is a full replacement while Revise Record is a partial one. Nothing about the names tells you that. VTQL is worth knowing too: Run VTQL Query takes a single table SQL-like statement, adds a trailing semicolon when omitted, and coreBOS caps a single query at one hundred rows, so paging is a real design consideration rather than an optimization. The coreBOS webservice publishes no event subscription, so this connector ships no triggers and change detection is a scheduled Run VTQL Query ordering on the module's own modified time field, discovered through Describe Module. Agents read and write any module. The verb that silently empties a record is where human-in-the-loop orchestration belongs.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Inbound records that land without flattening the ones already there
A survey response arrives from Typeform, or a batch of leads appears in Google Sheets. The agent begins with Describe Module for the target module, because the field keys, data types, mandatory flags, and picklist values are specific to this instance and a payload built from the labels a user sees on screen will be rejected or, worse, partially accepted. Search Records then checks whether the person already exists, matching a single field such as an email address against the inbound value; anything more nuanced goes through Run VTQL Query directly, since Search Records handles single field equality. Genuinely new people go in through Create Record, and where assigned_user_id is left out the record is assigned to the API user, which is a reasonable default and worth setting deliberately when it matters. Set Relation then links the new contact to the account it belongs to, so the record arrives connected rather than orphaned. The inbound rows that matched an existing record do not get written yet.
Reporting that respects the hundred row ceiling
A sales lead wants a weekly pipeline view. The agent uses Count Records first to find out how large the answer is, then Run VTQL Query with explicit limit clauses to walk the result in pages, because coreBOS caps a single query at one hundred rows and a flow that assumes otherwise silently reports a truncated pipeline as the whole pipeline. Get Related Records fills in the context a flat query cannot, such as the Contacts attached to each Account. The result appends to a tracker in Google Sheets and the exceptions post to Slack. Nothing in this run writes, and its value is entirely in being complete: a report that quietly stops at row one hundred is worse than no report, because somebody will act on it.
Enrichment that names the fields it is about to overwrite
An enrichment source returns job titles, company sizes, and phone numbers for contacts already in coreBOS. This is where the connector's sharpest edge sits. Update Record is a full replacement: it requires the record id and every mandatory field, and unspecified fields are reset to their defaults. Revise Record is the partial update that changes only what you supply and leaves everything else untouched. An agent enriching three fields on a contact record should almost always be calling Revise Record, and an agent that reaches for the action whose name reads like the operation it is performing will call Update Record instead. So the flow reads Get Record for the current state, compares it against the enrichment payload field by field, and puts the difference in front of the record owner before either verb runs. Mass Create Records is available for the genuine bulk load case, creating several records of one module in a single call, and it is a create rather than an upsert, so the deduplication check has to happen before it, not after.
Human-in-Loop Highlight
The operation to gate here is not a delete. It is the choice between Update Record and Revise Record, and it is a better gate than a delete because a delete announces itself. coreBOS documents the distinction plainly: Update Record is a full replacement that requires the record id and every mandatory field, and unspecified fields are reset to their defaults, while Revise Record is a partial update that changes only the fields you supply. Nothing in either name signals which is which, and both return an ordinary success. So the failure looks like this. An agent enriching contacts sends Update Record with id, email, title, and phone, because those are the fields it has. coreBOS accepts it. The description a salesperson wrote after a call, the custom field the operator added for territory, the source that told marketing where the lead came from, and every other value on the record are reset to their defaults in the same instant, on every record the batch touched, and the webservice answers HTTP 200 with a success envelope for each one. Nobody notices until somebody opens a contact three weeks later and the notes are gone. The information is not recoverable from the API, because nothing about the call recorded what was there before. So the agent makes the verb the decision. Before any write to an existing record it calls Describe Module for the module's full field set and mandatory flags, Get Record for the record's current values, and computes two lists: the fields the enrichment intends to change, and the fields that currently hold a value and are not in the payload. Then it posts to the record owner in Slack: "Enriching 43 Contacts from the vendor file. 3 fields would change: title, phone, and department. Update Record is a full replacement, so on these 43 records it would also reset 6 fields that currently hold values, including description on 29 of them and a custom territory field on 41. Revise Record would change only the 3 and leave the rest as they are. Revise, update, or show me the 29 descriptions first?" A person answers, and the agent runs the verb they chose. Delete Record sits behind the same gate for the plain reason that it is permanent, and Mass Create Records joins it because it creates rather than upserts, so a batch run twice produces a second copy of everything. This is the digital andon cord placed on the quietest destructive operation in a CRM, the one that reports success while it empties the record.
Agent Capabilities
14 actionsDiscovery
2- List Modules Lists every module available on the connected instance, covering Accounts, Contacts, Leads, Potentials, HelpDesk, and any custom modules your operator defined. The returned names are what the record actions expect.
- Describe Module Returns a module's field metadata: every field name, label, data type, mandatory flag, picklist values, and the operations the current user is permitted to perform. Because fields are instance defined, this is the call that turns a guess into a payload that will be accepted.
Querying
4- Run VTQL Query Runs a coreBOS VTQL query and returns the matching rows. VTQL is SQL-like, for example `select * from Contacts where lastname = 'Smith' limit 0,20`, and only a single table may be queried per statement. A trailing semicolon is added when omitted. coreBOS caps a single query at one hundred rows, so page explicitly.
- List Records Lists records of a module using a VTQL query built for you, with optional pagination, ordered by the module default. Reach for Run VTQL Query when filtering or sorting beyond simple paging is needed.
- Search Records Searches a module for records where a single field equals a value, using a VTQL query built for you. Partial or multi field matching goes through Run VTQL Query directly.
- Count Records Returns the total number of records in a module using a VTQL count query, with the count returned as a string in the `count` field of the single result row. Worth calling before a paged read so a flow knows how far it has to walk.
Records
6- Get Record Retrieves a single record by its coreBOS webservice id, in the composite `moduleId x recordId` form such as `11x24`, as returned by List Records, Search Records, or a query. The plain numeric id shown in the user interface is not that id.
- Create Record Creates a record in a module from a field values object keyed by the module field names from Describe Module. All mandatory fields must be supplied. When `assigned_user_id` is omitted the record is assigned to the API user.
- Update Record Updates an existing record as a full replacement. The field values object must include the record id and every mandatory field, because unspecified fields are reset to their defaults. Use this only when a full replacement is genuinely what you mean, and keep it behind a person when it is not.
- Revise Record Partially updates an existing record. Only the fields present in the field values object change and everything else is left untouched. This is the right action for enrichment, status changes, and any write that touches a handful of fields on a record somebody else curated.
- Delete Record Permanently deletes a record by its webservice id, returning a status object confirming the deletion. Cannot be undone.
- Mass Create Records Creates several records of the same module in one call from an array of field value objects, returning the created records. This is a create rather than an upsert, so deduplication has to happen before it rather than after.
Relationships
2- Get Related Records Retrieves the records related to a given record through a relationship, for example the Contacts related to an Account. Takes the source record id, its module, and the related module to fetch.
- Set Relation Relates one or more records to a source record, for example linking Contacts to an Account. Takes the source record id and an array of webservice ids to relate to it, so a record can arrive connected rather than orphaned.
Frequently Asked Questions
What can FlowRunner do with coreBOS?
FlowRunner agents can run List Modules, Describe Module, and Run VTQL Query in coreBOS, plus 11 more actions.
Does connecting coreBOS to FlowRunner require OAuth?
No. coreBOS connects to FlowRunner with session-based authentication, no OAuth flow required.
Can coreBOS trigger a FlowRunner workflow automatically?
coreBOS doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with coreBOS
$100 in credits. No card required. Connect in minutes.