Overview
The Search filter feature lets you define how you want to look up Customer or Transaction data. After creating a search filter, you can use the Copy cURL feature to import it into the API tool and run it.
Core Concepts
What is a Search Filter?
A search filter is a set of one or more indexed fields used to quickly look up data. You define which fields to search on—this setup is called the search filter .
There are two types of filters:
- AND filter – Returns results only when all the conditions are met
- OR filter – Returns results when any of the conditions are met (available only for the Customer entity)
Once the filter is set, the system knows how to query the database efficiently. You can then use the Search API to fetch the results.
Key Features
- Define the fields to search on—including custom and extended fields
- Set the time range for the data you want to query
- Supports partial search (starts with) for customer records
- Works across multiple languages
- Compatible with the Vulcan UI framework (but not limited to it)
- Choose which fields appear in the search results; use Neo for advanced customization
Understanding Cardinality
When creating a search filter, the system first checks the cardinality of the fields you've selected. Filters with high cardinality are more likely to pass validation and be activated.
-
High Cardinality means the field (or combination of fields) has a large number of unique values. This makes it a strong candidate for indexing and searching.
Example:Bill number—each value is likely unique. -
Low Cardinality means the field has only a few unique values. These fields aren’t ideal for filtering on their own.
Example:Gender—only a handful of values like Male, Female, Other. A filter with only this field will likely fail validation.
👉 Note: Cardinality is calculated based on all mandatory fields in your filter.
The filter must pass the cardinality check before it can be activated.
Search Filter Capabilities
| Entity | Filter Type | Filter Limit | Mandatory Fields Limit | Non-mandatory Fields Limit | Search Operators | Historical Data |
|---|---|---|---|---|---|---|
| Customer | OR | 2 | – | – | STARTS_WITH (partial search) | 10 years (based on registration date) |
| Customer | AND | 5 | 5 | 6 | EQUALS, RANGE (for date/datetime fields) | 10 years (based on registration date) |
| Transaction | AND | 5 | 5 | 6 | EQUALS, RANGE (for date/datetime fields) | 365 days (based on billing date) |
Example Flow
Step 1: Define Filter
- Customer entity
- Fields:
mobile OR email OR external ID - Filter type: OR
Step 2: Call Search API
- Endpoint:
v2/search/entity - Returns customer records that match any of the fields
Note for customer search in new MemberCare
Customer visibility in the new MemberCare depends on how the customer was registered and when the Cortex sync runs.
-
Import Framework registrations Customers registered through the Import Framework are not available for search immediately. Search feature requires a scheduled sync to make these customers searchable.
-
API-based registrations Customers registered through APIs are synced to the Search in real time through event notifications. You can search for these customers immediately in the new MemberCare.
-
Search sync schedule Search runs a daily sync at 12:00 AM (cluster timezone). For the seacrm cluster (JST), the customer will be searchable after 8:30 PM IST on the same day, once the sync completes.
Use this timing to verify customer availability before retrying the search.
Search auto-enable for new orgs
When a new org is created, the system automatically enables search and creates a default search criteria. No manual configuration or Jira ticket is required.
Note: If your org was created before this feature was introduced, search is not enabled by default. Raise a Jira ticket to the sustenance team to enable it and set up a search criteria.
During org creation, the system does the following automatically:
- Enables search for the org. Config key
262(search type) is set to enabled. - Creates a default prefix (OR) search criteria for the
CUSTOMERentity. The criteria supports searching by full name, email, external ID, or phone number.
Customers registered via API are immediately searchable in MemberCare using any of these fields.
Note: Customers registered through the Import Framework are not immediately searchable. They become available after the daily sync, which runs at 12:00 AM (cluster timezone).
Customization options
The default criteria covers the most common search use cases. You can extend or replace it based on your org's requirements:
- Custom fields: Add custom or extended fields to the search criteria using the Create search filter API.
- Custom event transformation: To modify how data is indexed before search (for example, stripping country codes from phone numbers), configure a custom Neo event transformation.
- Additional criteria: You can create up to two OR (prefix) criteria and up to five AND (combination) criteria per org for the
CUSTOMERentity.
Verifying search is enabled
To confirm the auto-created search criteria, use the Retrieve search criteria details API. If search does not appear to be enabled for your org, raise a ticket to product support.
The criteria shows as inactive for a few seconds after org creation. It becomes active automatically within a short time. No manual action is required.
Updated 12 days ago
