What it does

The Customers page renders every unified profile as a card, and the search & filter index decides which attributes appear on that card, which ones the search box actually searches, and which ones become filter facets down the side. It is a display and lookup configuration over the unified Customer table, not a data-processing step.

Key facts

• Cards are built from the unified Customer table. Until an admin adds at least one searchable attribute to the search & filter index, the tiles have nothing useful on them — this is the single most common "why is my Customers page blank-looking" complaint after a first unification.
• Searchable attributes must be of the Edm.String data type and flagged as included in search. Numeric and date columns cannot be searched, only filtered.
• Filtering supports string, number and date attributes. String filters take a result count and an order policy; number and date filters take intervals plus an order policy.
• Search is backed by Azure AI Search (the docs still call it Azure Cognitive Search). Terms are tokenised on spaces and hyphens, so "Nancy-Smith" is treated as Nancy AND Smith rather than as a literal.
• Index changes are not live. You add or remove attributes, then hit Run, and the page reflects the new configuration once that job finishes.
• Opening a card gives the profile detail view: a first block of predefined fields plus your indexed fields, address fields collapsed onto one line, then Additional fields for everything else, then IDs grouped by the source table each identifier came from.
• The same profile page hosts the activity timeline, measures, and brand/interest affinity results, but only where those have been configured separately.
• Filters applied on the Customers page can be saved straight out as a segment, which is the fastest way to hand a client a working segment in a demo.
• Profiles cannot be deleted from this UI. They are regenerated from source data on every unification run, so removal means fixing the source or the unification configuration.
• Microsoft's own guidance is to index low-cardinality fields with short values — index the value ("Blue"), not the field name ("Colour").

When to use / skip

You do not get to skip it. Every implementation needs the index configured, because without it the profile browsing experience is effectively broken and the client's first reaction to the product is a page of anonymous tiles. Treat it as a mandatory post-unification task, not an optional nicety.

Where judgement comes in is scope. Resist the urge to index thirty attributes because they all look useful. The index exists so a service agent or marketer can find one person or slice a rough cohort in a couple of clicks; anything more analytical belongs in segments. Six to ten well-chosen attributes — name, email, loyalty tier, city, customer status, maybe a source-system ID — will serve better than a wall of facets nobody scrolls past.

Configuration decisions

• Which attributes go on the card face. This is what everyone sees first, so pick the fields a human uses to confirm "yes, this is the right person", not the fields the data team finds interesting.
• Which of those are searchable versus filter-only. Remember searchable means string-typed, so if you want people searching on a customer number that landed as an integer, you need a string version of it produced upstream in Power Query.
• Filter facet shape per attribute: how many string values to surface, and what interval buckets make sense for numbers and dates. Age bands and spend bands need a deliberate choice here, not the default.
• Whether the indexed attribute set should mirror the fields the client's CRM users already search on, so the two systems feel consistent.
• Who owns re-running the index when the unified schema changes — this usually lands with whoever owns unification, and usually gets forgotten.
• Whether saved-filter segments are allowed as a working practice, or whether all segments must be built and named properly in the Segments area for governance reasons.

Gotchas

• Add a new attribute to the unified Customer table and it does not appear on cards until someone re-runs the index. Nothing errors; the field is just quietly absent.
• Indexing a high-cardinality field such as email address or a GUID gives you a filter facet with thousands of single-record values. It is useless and it makes the page feel slow.
• The card field order is decided by the system. You cannot drag fields into a preferred layout, so if a client insists on a particular arrangement, manage that expectation early.
• Search tokenisation catches people out with hyphenated names, reference codes like INV-2024-01 and anything containing spaces. Recommend unique single-token identifiers for lookups.
• Search only covers the unified Customer table. Activity content, enrichment output tables and measure values are not searchable from that box.
• Data quality shows up here immediately. Mixed casing, "UK" versus "United Kingdom", trailing whitespace — each variant becomes its own filter value, and the client will see it on day one.

Consultant notes

• Configure the index before the first client walkthrough, not after. A Customers page with recognisable names and a couple of sensible filters is the difference between "this is working" and "what am I looking at".
• Use it as a free data quality audit. Facet on country, status and tier during UAT and the normalisation gaps in the source data will be obvious without writing a single query.
• Demo the save-filters-as-segment path to business users — it is the one bit of the product they can genuinely self-serve, and it takes pressure off your segment backlog.
• Push back on requests to index every attribute "just in case". Offer to add fields on request after go-live instead; re-running the index is cheap.
• Before go-live, check that the profile detail page's IDs section shows identifiers from every source system the client expects. A missing block there usually means a source table never made it into unification.

---

Worth another look if the unified schema changes, or when Azure AI Search behaviour behind the search box shifts.