Initiative CRM

Connect AI agents to Initiative CRM, a French B2B CRM built on the Vtiger engine. Agents create and update contacts and records, raise tickets, attach documents, and inspect module metadata for custom fields.

14 actions Session available

Initiative CRM website ↗ Platform Documentation ↗

A scheduled poll, an inbound email, or a monitoring alert starts the run

Describe Module returns the fields and the picklist values this account actually uses

Count Records runs a filter to say whether the person or the account already exists

Get Record confirms the prefixed `NxID` belongs to the module the flow intends to write

Create Ticket opens the support record using the account's own stored status value

The assigned owner is told what was opened and which record it was attached to

A person approves the batch before Create Record inserts anything, because nothing here can be deleted

What This Integration Enables

Initiative CRM is a French B2B CRM built on the Vtiger web service model, and this connector treats it the way Vtiger intends: as a generic record engine with a small number of typed conveniences on top. List Modules and Describe Module tell an agent what the tenant's data model actually looks like, and Get Record, Create Record, Update Record, and Get Related Records then work against any module in it, including Accounts (Comptes), Contacts, Opportunities (Affaires), Quotes (Offres de prix), Products (Produits), Support Tickets (HelpDesk), and Documents. Create Contact, Update Contact, Create Ticket, and Update Ticket exist as typed helpers because those are the two objects that get automated most, and they are the two whose field sets the vendor documents verbatim. Everything else is reached through the generic path, which is a design choice rather than a shortfall: an account that added its own module gets the same coverage on day one as the modules that shipped with the product.

Three properties define how a careful agent behaves here. Record IDs are prefixed, in the form NxID, so 4x48 is a contact and 9x6617557 is a ticket, and reference fields such as account_id, parent_id, and assigned_user_id carry the same shape. The prefix is the module, which means an ID passed into the wrong action does not fail cleanly, it addresses the wrong object. VTQL queries target a single module, support no joins, and cap at 100 records unless a LIMIT clause is supplied, so joining a ticket to its account is work the flow does rather than work the query does. And the web service can answer HTTP 200 while reporting success: false in the body, so this connector inspects the envelope and raises the real error, which is why a missing mandatory field surfaces as MANDATORY_FIELDS_MISSING instead of passing as a quiet success. The most consequential property is an absence: the vendor's REST API documents create, retrieve, update, query, and related-record operations but no delete, so this connector does not delete records. There are no connectors listening for events here either. Initiative CRM ships no triggers to FlowRunner, so agents poll Search Records or Count Records on a schedule and use a stored high-water mark to find what changed.

Without FlowRunner

Duplicates are permanent A record entered twice has to be reconciled inside the CRM by hand, because there is no delete

Picklists are guessed Status and priority values are typed from memory and rejected, or accepted as the wrong thing

Tickets start life empty The alert arrives in a mailbox and someone retypes it into the CRM with whatever context they remember

With FlowRunner

Duplicates are prevented, not cleaned Count Records and Search Records run before the write, so the insert only happens when nothing matches

Picklists are read from the account Describe Module supplies the authoritative stored values, so writes land in the state they were meant to

Tickets arrive with their evidence The alert body, the related account, and the source record are attached at the moment the ticket opens

Use Case Scenarios

Monitoring alerts that become tickets with their evidence attached

An alert lands from a monitoring system or a shared support mailbox. The agent parses the customer identifier out of the message and calls Search Records against the Accounts module to resolve it to a prefixed ID, then Get Related Records to see whether an open ticket already covers the same symptom. Before writing anything, it calls Describe Module on HelpDesk, because Priority, Severity, Category, and Status are picklists the account can customize and the default French labels map to stored English values such as Ouvert to Open. With the authoritative values in hand it calls Create Ticket with the account reference, the parsed symptom, and the correct stored status, then Create Document With Attachment to store the alert payload or the log excerpt inside the CRM against that ticket. The support owner gets one message naming the ticket, the account it was attached to, and the existing ticket it was checked against.

An account import that cannot be undone, so it is checked first

A list of companies arrives from a spreadsheet in Google Sheets or an ERP export. For each row the agent calls Search Records against the Accounts module on the company name and, where available, the registration number, and Count Records to get a total before it iterates. Rows with exactly one match become Update Record, touching only the fields the source system genuinely owns. Rows with no match are held. They are not written immediately, because Initiative CRM exposes no delete and a duplicate account created by an agent stays in the tenant until a person merges it by hand. The agent posts the no-match set for approval, and only the approved rows become Create Record calls into Accounts.

Pipeline reporting that a query language without joins can still support

On a schedule, the agent calls Run Query with raw VTQL against the Opportunities module for deals expected to close this quarter, supplying an explicit LIMIT because results otherwise cap at 100. VTQL cannot join, so the agent takes the account_id reference off each row and calls Get Record against Accounts to resolve the company, then Get Related Records to pull the open tickets hanging off that account. The joined set goes into a sheet the sales lead reads, with a flag on any deal whose account has an open ticket in a severity band that usually delays a signature. Nothing is written back to the CRM in this flow, which is deliberate: the reporting run is read-only so it can be scheduled aggressively without a human gate.

Human-in-Loop Highlight

The gate on this connector sits on Create Record, and the reason is stated plainly in the vendor's own API documentation: Initiative CRM documents create, retrieve, update, query, and related-record operations, and no delete. This connector therefore has no delete action, and that is not a gap to route around, it is the fact that decides where a person belongs in the flow. On a CRM with a delete, an agent that creates a duplicate account has made a mess it can clean up. Here it has made a permanent one. The duplicate sits in the Accounts module until somebody with a CRM login merges it by hand, and every quote, ticket, and opportunity attached to the wrong copy has to be moved before that merge is safe. So the agent does the evidence gathering, which is the part it is genuinely better at, and stops. It runs Search Records on the company name, again on the registration number, and Count Records for a total, then posts to the sales operations owner in Slack: "63 companies in the import, 47 matched an existing account and will be updated in place, 16 found no match. Of those 16, four are near-matches on name where the registration number differs, listed below with both records side by side. Initiative CRM has no delete, so anything I create here is permanent until someone merges it. Create all 16, create the 12 clean ones and hold the four near-matches, or hold everything?" The owner answers in one reply, and only the approved rows become Create Record calls. This is the human-in-the-loop moment that exists because the platform's own capability list decided it, and the honest response to a write with no undo is to let the person who owns the data say yes to it.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

14 actions

Module Discovery

List Modules Returns the modules available in the tenant, including the ones this account added. Used as the first call in any flow that has to work against a data model it has not seen before.
Describe Module Returns a module's fields, types, and picklist values, along with the module prefix used in the `NxID` record ID format. This is the authoritative source for Priority, Severity, Category, and Status values, because those picklists are customizable per account.

Records

Get Record Retrieves a single record by its prefixed ID from any module. Also the practical way to confirm that an ID belongs to the module a flow is about to write into.
Create Record Creates a record in any module from a field payload. Because the platform exposes no delete, this is the action that runs on an approved set rather than optimistically.
Update Record Updates a record in any module. Used to enrich or correct a record without disturbing the fields another system owns.
Get Related Records Returns the records related to a given record, for example the tickets or contacts hanging off an account. VTQL cannot join, so this is how a flow assembles a picture that spans more than one module.

Query and Search

Run Query Runs raw VTQL against a single module for multi-condition filters and unusual comparisons. Results cap at 100 records unless the query supplies its own `LIMIT` clause.
Search Records Runs a guided filter against one module, where string values are single-quoted and reference IDs in `NxID` form and plain numbers are matched unquoted. Used for the dedup check before any create.
Count Records Returns a count for a filter without pulling the rows. Used to size a job before it starts and to answer existence questions cheaply on a schedule.

Contacts

Create Contact Creates a contact with the typed field set the vendor documents. Used as the entry point for inbound people from forms, email, and imports.
Update Contact Updates an existing contact. Used to keep CRM contact detail aligned with a billing system or a support tool without overwriting what a rep entered.

Tickets

Create Ticket Opens a HelpDesk ticket against an account or contact. Priority, Severity, Category, and Status ship the default Initiative CRM values, so an account with customized picklists should pass its own stored values through Additional Fields.
Update Ticket Updates a ticket, including its status and priority. Used to reflect progress that happened in a monitoring system or a support tool rather than in the CRM.

Documents

Create Document With Attachment Stores a file inside the CRM against a record, using the internal file location type. External document links cannot be created through this operation, so the file lives in Initiative CRM rather than being referenced from elsewhere.

Frequently Asked Questions

What can FlowRunner do with Initiative CRM?

FlowRunner agents can run List Modules, Describe Module, and Get Record in Initiative CRM, plus 11 more actions.

Does connecting Initiative CRM to FlowRunner require OAuth?

No. Initiative CRM connects to FlowRunner with session-based authentication, no OAuth flow required.

Can Initiative CRM trigger a FlowRunner workflow automatically?

Initiative CRM doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Initiative CRM

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us