rules object when you mint a token:
Attribute roles
Every attribute on an index falls into one or more of three roles.
Filterable and sortable attributes are configured per tenant when Discovery is provisioned, because indexing every attribute for filtering costs storage and slows writes. Which ones are enabled on your indexes is a provisioning decision, so confirm it with your Omneo account manager rather than assuming.
Each index also has a primary key that uniquely identifies a document. On the standard indexes this is
id, carrying the Omneo ID of the underlying record.
Discovering what an index holds
Two calls tell you most of what you need. Run an empty search to see the shape of a document:400 means the attribute is not filterable on this index.
The profiles index
Holds one document per Profile. This is the index behind staff profile lookup in Clienteling and behind any customer search box you build.
Searching a phone number or a loyalty card number works because
identifiers and the phone attributes are searchable, so a single q covers name, email, phone, and card number without the caller deciding which one the user typed.
The products index
Holds one document per Product.
Other indexes
Two further indexes can be enabled on request. They are not part of a standard deployment.locations
One document per Location, with id, name, handle, type, external_id, external_code, is_published, is_permanently_closed, phone, email, timezone, tags, and the address broken out as address_line_1, suburb, state, postcode, and country.
Locations also carry a _geo attribute holding lat and lng, which makes distance filtering and sorting available for store locators:
_geoPoint sorting returns nearest first.
product-lists
One document per Product List, with id, name, handle, item_count, items, the owning profile_id alongside that Profile’s first_name, last_name, and email, the List Definition as definition_id, definition_name, and definition_handle, plus location_id, location_name, staff_id, and staff_full_name.