What the EspoCRM Intelligence extension changes for your sales and service teams
Your sales and service teams want AI summaries and drafted emails inside EspoCRM, but you still have to decide where customer data goes and what the usage costs. The Intelligence extension adds record summaries, Intelligent Paste, an AI Email Composer and AI formula functions, plus a usage log and quotas. It requires EspoCRM 10.0.3 or later. Before rollout, you decide which provider serves each feature, whether requests leave your network, and what spend limits apply. Those decisions shape the architecture more than the feature list does.
The extension works per entity type and per role. Summary and Intelligent Paste are enabled for each entity in the Entity Manager and then controlled by role scopes, so a sales role can summarize opportunities while a service role works only with cases. The summary sends the record name, description and stream history to the model, and the stream history is omitted for users who lack stream access. Review that behavior against your access model, since a summary can expose information a user could not otherwise read in one place. Confirm the exact fields each feature sends with the EspoCRM Intelligence documentation before you approve a provider.
Intelligence does not replace your CRM data model, your permission design or your approval process for outbound email. Drafts still need a human sender, and the composer does not decide what a customer should hear. Plan the rollout with a pilot group, a review of the usage log and quotas, and a named owner for provider keys and model changes. Ask any implementation partner to price the provider connection, role and entity configuration, and testing as separate items, since the model hosting choice drives most of the recurring cost.
What Intelligence does in EspoCRM, feature by feature
The Intelligence extension adds four AI features to EspoCRM, plus the controls that decide who uses them, which model answers, and what they cost. Each feature sends a different slice of CRM data to a model, so the questions that matter are what leaves the instance, who can trigger it, and how spend is capped.
Record summaries
Summary is enabled per entity type in the Entity Manager and controlled by role scopes, so you decide which record types can be summarized and by whom. The request sends the record name, the description and the stream history to the AI provider. If a user lacks stream access, the stream history is omitted from the request. Before rollout, confirm which entity types hold sensitive free text, because that text is what the summary reads.
Intelligent Paste
Intelligent Paste takes unstructured text, such as an email signature or a pasted message, and proposes structured field values for a record. Like summaries, it is switched on per entity type in the Entity Manager and gated by role scopes. Review what the pasted text contains before users start pasting, since anything pasted is sent to the configured provider. Test it on your own entity layouts so that mapped fields land where your team expects.
AI Email Composer
The AI Email Composer drafts outgoing email for a user to review and send. Drafts are a starting point, not a sent message, so the approval step stays with the sender. Decide which mailboxes and roles can use the composer, and set expectations on tone, signatures and disclaimers with your communications or legal team. Check how drafts interact with your existing email templates before you publish guidance to sales staff.
AI formula functions
The extension adds AI functions to EspoCRM's Formula Script, so AI output can be used inside before-save scripts, workflows and BPM logic. This makes automated writes possible without a person in the loop, which raises the stakes for validation. Each formula call is a model request, so review where these functions run and how often. Test failure handling, since a provider timeout should not block saving the record.
Usage log and quotas
The usage log records AI requests so administrators can see who used which feature and how often. Quotas cap that use, which is the main control on spend when a provider bills per request or per token. Set quotas before opening the features to all users, and review the log after the first weeks of use to tune them. Confirm with the vendor how the log records token counts and which fields it keeps.
Per-feature model overrides
The model can be overridden per feature, so a cheap, fast model can handle summaries while a stronger model handles email drafting, or a self-hosted model can serve one feature while a hosted one serves another. Choose overrides by data sensitivity as well as quality, because each override changes where the text goes. Document which feature uses which provider so that audits and incident reviews can trace the data path.
Which AI provider and model setup fits your data and budget
This table compares the hosted providers Intelligence supports with a self-hosted OpenAI-compatible option, showing where record data goes, who runs the model and when each fits. Read the data location and access control rows first, because they decide whether a provider is acceptable before cost comes into the discussion.
| Option | Where record data goes | Who runs the model and access control | When it fits |
|---|---|---|---|
| OpenAI | Summary and drafting inputs leave your network for the provider's API | Provider runs the model. Access is controlled by your API key and provider account settings | Teams that accept a hosted provider under their contracts and data terms |
| Gemini | Inputs leave your network for the provider's API | Provider runs the model. Confirm key handling and data terms with the provider | Teams already standardized on Google Cloud contracts and accepting hosted inference |
| Claude | Inputs leave your network for the provider's API | Provider runs the model. Confirm key handling and data terms with the provider | Teams that prefer Anthropic models and accept hosted inference |
| Custom OpenAI-compatible endpoint, self-hosted | Stays inside your network if the endpoint is reachable only internally | Your team runs the model and the gateway. You must set authentication and network limits | Records are sensitive and you have accelerator capacity and staff to operate it |
| Ollama behind a proxy | Stays on your hardware when run locally with cloud features turned off | Local API at port 11434 has no authentication by default, so a reverse proxy with access control is required | Smaller models on modest hardware for summaries and drafts, with limited concurrency |
| vLLM behind a reverse proxy | Stays inside your network when nodes are isolated | --api-key does not cover every endpoint, so allowlist only the user-facing paths at the proxy | Higher throughput and multi-GPU serving, with staff to run accelerators and monitoring |
| Per-feature model choice | Depends on the model chosen for each feature, so each feature may send data to a different place | Set in Intelligence settings. Confirm which features use which provider before go-live | Summaries on a local model and drafting on a hosted model, if your data policy allows it |
How self-hosted models with Ollama and vLLM differ in operation
Ollama suits a single server or a small team that wants a local model endpoint with little setup. Its defaults keep the service private: the local API listens on 127.0.0.1 port 11434 and does not require authentication, so anything beyond the same host has to be added deliberately. Operating work centers on the host, its disk and the concurrency limits that decide how many users wait behind each other.
- Local binding: The default bind address is 127.0.0.1:11434. To let the EspoCRM server reach it from another host, set
OLLAMA_HOSTand place a reverse proxy with authentication and TLS in front of it, as the Ollama FAQ describes. - Model storage: Models live in a default path that differs by operating system, and
OLLAMA_MODELSmoves them. Plan disk size and backups for that directory. - Concurrency defaults:
OLLAMA_NUM_PARALLELdefaults to 1 request per model,OLLAMA_MAX_LOADED_MODELSto 3 times the GPU count (or 3 on CPU), andOLLAMA_MAX_QUEUEto 512 queued requests. Summaries and drafts from several users may queue, so test these under your expected load. - Cloud features: Ollama offers paid cloud plans, and direct cloud inference needs an API key. For data that must stay local, set
OLLAMA_NO_CLOUD=1or the equivalent server configuration entry.
Before choosing Ollama, confirm the server's hardware, the proxy design and the concurrency settings against the number of staff who will use the feature at the same time.
vLLM is an inference and serving engine built for higher request volumes and multi-GPU serving. It exposes OpenAI-compatible endpoints, so the Intelligence extension can point at a custom OpenAI-compatible provider. The trade-off is more infrastructure: accelerator selection, parallelism settings, network isolation and metrics collection all become part of the platform your team runs.
- Compatible endpoints:
vllm serveprovides/v1/chat/completions,/v1/completionsand/v1/embeddings, among others. Confirm which of these your EspoCRM feature calls before you publish the endpoint. - Accelerators: vLLM runs on NVIDIA CUDA, AMD ROCm and Intel XPU GPUs, and on several CPU and Apple silicon platforms. Validate your model and accelerator combination before procurement.
- Parallelism: Tensor parallelism spreads a model across GPUs within a node, and pipeline parallelism spans nodes. Multi-node communication is insecure by default, so isolate those nodes on a private network.
- Reverse proxy allowlisting: The
--api-keyoption does not cover/metrics,/healthor several other paths. Use a reverse proxy that exposes only the endpoints users need, and keep/metricsfor internal monitoring. - Kubernetes options: The vLLM docs list native manifests, Helm, the production-stack, KServe, KubeRay and others. Pick one your platform team can operate.
vLLM has no paid edition. Its cost comes from accelerator capacity, the surrounding infrastructure, implementation and the people who operate it, so ask for those components in any quote.
Both servers can be reached by the EspoCRM application, but neither should be exposed directly to users or the internet. The security work is mostly about what sits between the CRM and the model server: which paths are published, who can reach them and what gets logged. Design this boundary before the Intelligence extension is pointed at either server.
- Ollama boundary: Keep the default loopback binding unless a proxy is in place. When you expose it, the proxy should handle authentication and TLS, and the model host should accept connections only from the EspoCRM server.
- vLLM boundary: Publish only the inference endpoints through an allowlisting proxy. Keep
/metrics,/pause,/resumeand/abort_requestsoff the user-facing path. - Data flow: Record summaries send the record name, description and stream history to the AI provider. Confirm which fields leave the CRM and where the model server logs prompts.
- Network isolation: Put model servers on a segment with restricted egress so they cannot reach external services unless a decision says they should.
- Access control: Use dedicated service credentials for the CRM connection and rotate them under your normal secrets process.
Confirm with your security team how the model endpoint is authenticated, which paths are exposed and whether prompts and outputs are logged, because those answers determine the boundary you build.
The day-to-day difference between the two is who runs them. Ollama is closer to a managed service on one host, with monitoring focused on disk, memory and queue length. vLLM is closer to a serving platform, with metrics, scaling, upgrades and accelerator health owned by a platform team. Release cadence also matters, since both projects publish frequent releases that need testing before deployment.
- Monitoring: vLLM exposes Prometheus-format metrics at
/metrics, covering request counts, token throughput, latency and KV cache use. Ollama requires host-level monitoring plus your own checks on queue behavior. - Upgrades: Ollama and vLLM both ship frequent releases. Test each upgrade against your model and the Intelligence extension before rollout, and keep the previous version available for rollback.
- Capacity planning: Load tests should use realistic record summaries and drafts, including long stream histories, to find queue and latency limits.
- Skills: vLLM deployments usually need people comfortable with GPU drivers, container orchestration and distributed systems. Ollama needs fewer specialists but still requires patching and access control.
- Support model: Decide whether the platform team, an internal AI group or an outside partner will own incidents and upgrades.
Ask your team to estimate the operating hours each option requires, based on your own staffing and environment, before comparing them.
How to roll out Intelligence from pilot to all users
This sequence moves the Intelligence extension from a configured test instance to a controlled rollout, so each provider, permission and spending limit is proven with a small team before everyone gets access. Each step produces a record of what was set, who approved it and what the usage log shows.
Confirm the EspoCRM version and extension prerequisites
The engineer responsible for the instance checks that the server runs EspoCRM 10.0.3 or later, the minimum version the Intelligence extension requires, and that the extension is installed from the Extension Manager on a non-production copy first. Confirm the PHP, database and cron requirements for your installed version against the server configuration docs. The output is a short build record listing the EspoCRM version, extension version and any deviations from the documented requirements.
Choose providers and models for each feature
The platform owner and the data protection lead agree which provider serves which feature. The extension supports OpenAI, Gemini, Claude and custom OpenAI-compatible providers, and the model can be overridden per feature, so summaries, Intelligent Paste and the Email Composer may use different models. Record the data each provider receives, where it is processed, and the contract terms that govern it. The output is an approved provider register that names one model per feature.
Set up the endpoint and network path
For a self-hosted model, the infrastructure team deploys the runtime, such as Ollama or vLLM, and exposes only the endpoint EspoCRM needs through a reverse proxy with authentication and TLS. Confirm the authentication behavior of your chosen runtime before exposure, since local Ollama requires no authentication by default. Test the connection from the EspoCRM server, not from a workstation, and confirm the instance can reach the endpoint and nothing else. The output is a tested connection and a documented firewall rule.
Enable Summary and Intelligent Paste per entity type
The EspoCRM administrator opens the Entity Manager and enables Summary and Intelligent Paste only for the entity types in the pilot, such as Account or Opportunity for the pilot team. Each enabled entity sends its name, description and stream history to the configured provider, and stream history is omitted for users without stream access, so review what each entity holds before enabling it. The output is a list of enabled entity types with a note on the data each one sends.
Set role scopes for the pilot team
The administrator creates or adjusts a role for the pilot team and grants Summary and Intelligent Paste access only through role scopes, leaving all other users without the feature. Test each role with a pilot user account rather than an administrator account, because admins can see features that ordinary users cannot. The output is a role matrix showing which roles can use each AI feature and an access test result for each role.
Configure the Email Composer and formula functions
The administrator configures the AI Email Composer and any AI formula functions for the pilot team, and reviews the prompts and settings that shape drafts. Drafts are suggestions that a person must review and send, so the pilot should confirm that reviewers know to check facts, names and commitments before sending. Where a formula calls a model, confirm the expected cost and latency with the pilot group before it runs on many records. The output is a documented configuration and a set of sample drafts reviewed by the team.
Set quotas and review the usage log
The administrator sets quotas for the pilot users and checks the usage log to confirm that each feature, model and user is recorded as expected. Run a representative set of test actions and compare the logged activity with the provider invoice or the runtime's own metrics. Ask the vendor or your provider how billing is calculated, since the usage log shows EspoCRM's view of requests, not the provider's billing unit. The output is a quota policy and a reconciled usage report for the pilot.
Pilot with one team before wider enablement
A single sales or service team uses the features for a defined period agreed in advance, with a named owner who collects feedback on summary accuracy, draft quality, response times and quota use. Review the usage log and any errors at the end of the pilot, and decide which entity types, roles and models to keep. Widen access only after the owner signs off on the pilot record, and repeat the Entity Manager and role scope steps for each new group. The output is a signed pilot report and an approved expansion plan.
How quotas, the usage log and role scopes keep AI spend and data exposure in check
The controls that matter most for the Intelligence extension decide two things: who can send record data to a model, and how much each feature consumes. Role scopes are the first gate. Summary and Intelligent Paste are enabled per entity type in the Entity Manager and then governed by role scopes, so a role that has no access to an entity type cannot trigger AI on its records. Review every role that can read Accounts, Contacts, Opportunities or Cases, and decide explicitly which of them should see the AI actions. Treat the default as something to verify in your own instance rather than assume.
Stream access is the second gate, and it is easy to overlook. According to the EspoCRM Intelligence docs, the summary sends the record name, description and stream history to the AI, and the stream history is omitted when the user lacks stream access. That means the same record can produce a summary with different content depending on who clicks the button. Test this with at least one restricted user and one unrestricted user on a sample record, and confirm what each one's summary actually contains before you widen access to a team or portal.
Quotas and the usage log control spend. Confirm in the Intelligence docs how quotas are set, at what level they apply (per user, per feature or overall) and what happens when a limit is reached. Read the usage log to see consumption per feature, and check whether it is retained long enough for your finance review. Also confirm whether per-feature model overrides change how usage is counted, because a cheaper model for summaries and a more capable one for email drafting produce different cost profiles. Document the owner who reviews the log and how often.
What drives the cost and effort of an AI rollout
This table lists the cost and effort drivers of enabling Intelligence in EspoCRM, who is paid for each one, and whether it is one-time or recurring. Use it to build the scope you send to a partner or to your own team, and to check that a quote covers each row. The main takeaway is that the model choice is only one line of the budget, while data review, network work and ongoing updates usually decide the total effort.
| Cost driver | What it involves | One-time or recurring | What to ask for in a quote |
|---|---|---|---|
| Entities and layouts enabled | Each entity type that shows summaries or Intelligent Paste is configured in the Entity Manager and gated by role scopes, so testing and layout changes scale with the count | One-time setup, then recurring when new entities are added | Named list of entities, layouts and roles in scope, and how changes after go-live are handled |
| Providers and models | Each provider (OpenAI, Gemini, Claude or a custom OpenAI-compatible endpoint) needs keys, endpoint settings and a model choice per feature where overrides are used | One-time configuration, recurring when keys rotate or models change | Which providers and models are configured, who holds the API keys, and how overrides are tested |
| Self-hosted model hardware | A local or private model needs accelerator or CPU capacity, storage for model files and capacity planning for concurrent requests | Hardware is a capital or hosting cost; power, hosting and replacement recur | Hardware specification the vendor requires, sizing assumptions, and whether capacity is shared with other workloads |
| Network, TLS and access control | The model endpoint must be reachable from EspoCRM only, typically behind a reverse proxy with TLS and an allowlist of the endpoints users need | One-time design and build, then recurring certificate and rule reviews | Network diagram, firewall rules, certificate ownership and an access review schedule |
| Prompt and data review | Compliance and data owners confirm which record fields and stream history leave the system for each provider, and which records are excluded | One-time review, repeated when features or providers change | Written data flow for each provider, exclusion rules, and the owner who signs off each feature |
| User training and adoption | Sales and service users learn when to use summaries, how to check drafts and what the usage log shows | One-time delivery, with recurring onboarding for new staff | Training materials, session count, and whether training covers review habits as well as clicks |
| Model and version updates | Intelligence releases, EspoCRM upgrades (the extension requires 10.0.3 or later) and provider model changes need regression checks on prompts and outputs | Recurring for the life of the system | Upgrade test plan, responsibility for provider deprecation notices, and retest scope per change |
| Usage quotas and spend control | Usage log and quotas are set per feature and user group, and someone must review them against provider invoices | Recurring monitoring; quota design is one-time | How quotas are set, who reviews the usage log, and how overruns are reported |
Questions buyers ask before adding AI to EspoCRM
What does adding AI to EspoCRM cost, and what drives the price?
The software cost is the Intelligence extension itself plus the model you choose, and the engagement cost is the work to configure, test and roll it out. The model cost is the variable part: hosted providers bill by usage, while a self-hosted model shifts spend to hardware, power, hosting and the people who run it. Engagement effort rises with the number of entities that get summaries, the number of AI features enabled per role, how many models you route to, the depth of formula work and the testing your compliance team requires. Ask any partner for a fixed-scope quote that lists each cost component separately, and confirm with your EspoCRM provider which extension licensing applies to your edition.
How long does a pilot of EspoCRM Intelligence usually take?
A pilot is usually short when it covers one team, one or two entity types and one provider, and it lengthens when you add self-hosted models, several roles or formula functions. The main time sinks are not the setup itself but getting an approved provider, agreeing what data the summary may send, and reviewing the outputs with sales or service leads. The Intelligence extension requires EspoCRM 10.0.3 or later, so confirm your current version first. A written scope should fix the timeline for each phase before work begins.
What does our team need to provide for an AI rollout?
You need a named business owner who decides which entities and roles get AI features, an administrator who can change the Entity Manager and role scopes, and someone who can approve the data flow to each provider. If you self-host a model, you also need infrastructure access and staff who can operate a model server. Gather your current stream and description data policies before the pilot, because the summary sends the record name, description and stream history to the AI, omitting stream history when the user lacks stream access. Sales and service users should be available for review sessions.
Can our own team set up EspoCRM Intelligence without a partner?
Yes, a capable EspoCRM administrator can enable summaries, Intelligent Paste and the email composer for specific entity types and roles, because these are configured in the Entity Manager and role scopes. A partner adds the most value where the decisions are harder: choosing and hardening a self-hosted model endpoint, designing per-feature model overrides, setting quotas, testing prompts against your data, and producing the change records your auditors will ask for. Decide based on whether anyone on your team has run an inference service and whether you need documented evidence for an assessment.
Does self-hosting a model keep our CRM data in-house?
It can, but only when the whole path stays inside your network. Ollama states that when it runs locally it does not see your prompts or data, and you can turn off its cloud features with OLLAMA_NO_CLOUD=1. Ollama's local API at localhost:11434 requires no authentication, so exposing it through a proxy needs its own access control. vLLM's security docs say its own API key does not cover every endpoint and recommend a reverse proxy that allowlists only the endpoints users need. Confirm with your security team that the EspoCRM server, the model host and any proxy all sit within your approved boundary, and that no cloud model is called by accident.
What are the recurring costs after the pilot?
Recurring spend has three main parts: model usage, infrastructure and support. Hosted providers charge according to their own pricing, so use the usage log and quotas in the extension to set limits per feature and per user before wide rollout. Self-hosted models carry ongoing compute, storage and operations cost, plus upgrades for the runtime and model files. Ollama lists paid cloud plans, with its Enterprise plan adding cost budgets per user or API key, and states that running models on your own hardware is always unlimited. Ask every provider for its current rate card and model retirement policy, and budget for a regular review of the usage log.
Which AI features carry the most compliance risk?
The record summary carries the most exposure because it sends record name, description and stream history to the model, so you must confirm which entity types and roles can use it. Intelligent Paste and the email composer send text that users paste or draft, which can include personal data that was never meant for a third party. Document which providers are approved for which data classes, restrict summaries by role scope, and keep the usage log as evidence of who used which feature. DeployOpen prepares systems and evidence for compliance assessments, but independent auditors issue any audit report or certification.
How Intelligence connects to the rest of your EspoCRM platform
Intelligence does not run alone. Its summaries, paste parsing and email drafts depend on the stream data, roles, mailboxes and formula logic already in your EspoCRM, and its model traffic depends on infrastructure you operate. The cards below show each connection and what to confirm before you enable features for users.
Formula Script for AI functions
Intelligence adds AI functions to Formula Script, the scripting language EspoCRM uses in before-save scripts, workflows and BPM. Formulas that call a model run wherever the formula runs, so a function placed in a before-save script can fire on every save. Confirm which records and roles trigger each formula, and check the usage log after testing so that a loop or bulk update does not multiply model calls.
Advanced Pack workflows and BPM
Workflows and BPM from the Advanced Pack can call AI functions as steps, for example to draft a follow-up or classify an incoming case. Each automated call counts against the same quotas and usage log as a user action, so confirm whether automated runs have their own limits in your version. Test scheduled rules against a copy of production data before enabling them for all records.
Email setup for the Composer
The AI Email Composer drafts messages that you still send through EspoCRM's mail configuration. Confirm that the user's personal or group mailbox is connected and that the sending address is the one your customers expect. Review how drafts pull in record and stream content, so that the mail sent to a customer never includes internal notes that a user could otherwise have hidden.
Roles, teams and API users
Summary and Intelligent Paste are controlled by role scopes, and a summary includes stream history only when the user can access the stream. Set roles per entity type and test with a standard user, not an administrator. If integrations call EspoCRM's REST API, use a dedicated API user with the narrowest role and HMAC authentication, which the docs describe as the most secure method.
Self-hosted model endpoint
A self-hosted model behind an OpenAI-compatible interface keeps prompts inside your network. Ollama binds to 127.0.0.1 on port 11434 by default and does not require authentication locally, so expose it only through a reverse proxy that enforces access. vLLM's documentation recommends a proxy that allowlists only the endpoints users need, because its own API key option does not cover every route. Confirm which endpoints EspoCRM calls before you write the allowlist.
Monitoring and spend tracking
Track model health and usage in the same operations stack you use for EspoCRM. vLLM exposes Prometheus-format metrics at /metrics covering request counts, token throughput, latency and KV cache use. Do not expose that path publicly. Compare these metrics with the Intelligence usage log to find slow responses, failed calls and quota pressure before users notice them.
How DeployOpen scopes and delivers an EspoCRM Intelligence rollout
DeployOpen starts an Intelligence rollout with a written scope that fixes the decisions before any configuration begins. The scope names each AI provider and model, including whether a self-hosted OpenAI-compatible endpoint is in use, and assigns a model to each feature where the per-feature override is needed. It also records the data paths: which entity types expose record summaries and Intelligent Paste, which role scopes grant access, and whether stream history is included in what is sent to the model. Access to these settings is controlled by roles, so the scope lists the roles that may use each feature and the roles that may change provider settings or read the usage log.
The deliverables follow from that scope. DeployOpen configures the provider connections, the Entity Manager settings and role scopes, and the quotas and usage log that limit spend. For a self-hosted model, the network and reverse proxy work is part of the same deliverable, so the model endpoint is reachable only from the EspoCRM server and is not exposed to users directly. The package also includes documentation of the configuration and a handover session for administrators and the teams who will use the features. Confirm with your provider and your own environment which EspoCRM version you run, since the extension requires EspoCRM 10.0.3 or later.
Ongoing work is handled separately. Model changes, provider updates, quota tuning and extension upgrades can be covered by a retainer for ongoing support rather than a one-off project. DeployOpen does not publish a price list, so the quote follows from the written scope, and the cost components depend on the number of providers, entities, roles and integration points you choose. Ask for the scope, the deliverables, the assumptions about your environment and the terms for changes before you sign. Those documents tell you what is one-time work and what recurs.
