Acumatica's built-in global search — the search box in the top bar — is a SQL Server-backed keyword search over a fixed set of indexed screens and fields, not Elasticsearch, and there is no native Elasticsearch integration shipped with the platform. If a requirement specifically calls for Elasticsearch — typo-tolerant fuzzy search, faceted filtering across large catalogs, sub-100ms search-as-you-type over hundreds of thousands of items — that is custom integration work you build alongside Acumatica, not a setting you enable inside it. Worth being upfront about that before scoping the work.
What the native search actually covers, and where it runs out
Acumatica's global search indexes a configurable set of DACs (Search screen, SM200600-adjacent configuration depending on version) into SQL Server's full-text search infrastructure. It is genuinely useful for "find this customer/invoice/case by number or name" and scales fine for that use case up into the low millions of rows, because full-text catalogs in SQL Server are a mature, well-optimized feature. Where it runs out: relevance ranking is basic compared to a proper search engine's scoring, there is no faceting UI (filter search results by category/price range/status interactively), fuzzy/typo tolerance is limited, and cross-language stemming/synonym handling is minimal. A B2B customer portal with a large item catalog that needs e-commerce-grade search is the recurring scenario where this gap actually matters.
The integration shape I actually build
Elasticsearch (or OpenSearch, or a managed alternative) sits alongside Acumatica as an independent service, kept in sync via one of two patterns depending on freshness requirements:
- Scheduled bulk sync via GI + OData/REST. A GI shaped for the searchable entity (item catalog, customer list), exposed via OData or the contract-based REST API, pulled on a schedule by a small indexing job that upserts documents into Elasticsearch. Simple, reliable, and adequate freshness (minutes to hours of lag) for most catalog-search use cases.
- Event-driven sync via Business Events / webhooks. Acumatica's Business Events framework can fire a webhook on record insert/update, which a small consumer service turns into an Elasticsearch document upsert — near-real-time freshness for cases where "the item I just updated should be searchable immediately" actually matters.
{
"inventoryID": "WIDGET-001",
"description": "Blue Widget, 10cm",
"itemClass": "FINISHED",
"priceListPrice": 24.50,
"onHandQty": 340,
"isActive": true,
"_syncedAt": "2026-07-09T06:00:00Z"
}The search UI itself is then a separate component — a portal search box, a custom widget — that queries Elasticsearch directly for the fast, faceted experience, and only falls back to Acumatica for the authoritative record (stock levels, pricing, availability) once a user picks a specific result, since search-index data is inherently a lagging, denormalized copy and must never be treated as the source of truth for anything transactional.
It is tempting, once Elasticsearch is fast and convenient, to start reading stock quantities or prices directly from the search index in the UI to avoid an extra Acumatica round trip. Do not — the index is only as fresh as your last sync, and quoting a stale on-hand quantity or price to a customer is a business problem, not a technical inconvenience. Use the index for discovery (find the item) and always hit Acumatica live for anything that needs to be current at the moment of the transaction.
What you are actually signing up for
An Elasticsearch integration means running (or paying for a managed) Elasticsearch cluster, writing and maintaining the sync job, handling schema drift when custom fields get added to the indexed DAC, and monitoring sync lag. This is a real, ongoing infrastructure commitment, not a one-time integration project — budget for it accordingly and make sure the search requirement is valuable enough to justify a permanently running extra service, rather than reaching for it because SQL full-text search feels old-fashioned.
Wrapping up
There is no native Elasticsearch integration in Acumatica — native global search is SQL Server full-text search, adequate for lookup-by-identifier use cases and limited for faceted, fuzzy, catalog-scale search. When the requirement genuinely needs the latter, build Elasticsearch as an independent service synced via GI/OData or Business Events, keep it strictly read-only and non-authoritative, and budget for the ongoing operational cost of a second running system.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.