Please add Azure Search to the HIPAA BAA so we can use it in healthcare software.

I am now stuck at recreating indexes. I was told to delete one of my index to create another, but it didn't work. The funny thing is that, I am only having just 1 active index in that Azure Search Repo.

Response that i get when I want to 'Import Data':
'You have exceeded the free quota of 3 indexers. Please delete one to continue'

The lucene query syntax for proximity search allows us to find 2 terms X number of words apart.

https://docs.microsoft.com/en-us/rest/api/searchservice/lucene-query-syntax-in-azure-search#bkmk_proximity

A search for "hotel airport"~5 could return documents with "Find a hotel airport" or "hotel near airport" or "going to airport? check out this hotel".

It would be a big benefit to our clients if we could have a mode for proximity search where it doesn't matter what the order of the words are, as well as a different, more restrictive mode, where proximity search will only find results with the words in in explicit order.

You can see full details here:
http://stackoverflow.com/questions/43505244/how-to-make-searches-more-natural/43509264#43509264

The idea is to have something like:
EnableFuzzy, Enable PartialMatching on the SearchParameters to avoid constructing weird search strings.

Some applications can have a large number of facets and it is inconvenient to have to specify them all explicitly in the Search API, as reported here: http://stackoverflow.com/questions/28542665/azure-search-what-if-i-have-a-lot-of-facets

If there were an option like facet=* that returned facets on all facetable fields, that would be easier for such cases.

We have large scehams that define individual aspects of healthcare data. We would like to use these schemas to define the fields than entering most of these manually. For this to work, obviously we need support for crawling XML data (similar to what you have for JSON). XML provides a good structure and has many industry standard schemas that we can leverage.

If I create a MongoDB collection backed by DocumentDB, I should be able to use the DocumentDB indexer to ingest it into Azure Search.

Similar to Solr's (small) capabilities
https://cwiki.apache.org/confluence/display/solr/Learning+To+Rank

Consider the situation that, two document have some same property and I want to select those same fields and count the document as one(distinct) and select that distinct document.

We have difficulty in transferring documents where we require multiple maps of our data into the flat search index. There is a limit of two user defined functions (which we use to do this) and there doesn't appear to be a way to call a stored procedure through the query language. Having the search indexers support DocumentDB stored procedures gives us far more power and flexibility to map the data correctly. At the moment we have had to revert back to writing our own code to do this.

Having WebJob in process to execute before Indexing while we want to reply events from eventstore and create the DB

Support indexing structured data (e.g. schema.org) in HTML documents.

Support a mix of JSON and non-JSON blobs in the same data source

We create a lot of indexes for experiments. Over time it becomes harder to remember the differences between indexes with similar names. We could add something to the index name to distinguish them. But it makes the name messy. It'd be better to have a description field in index to describe what the index is.

I would like to have a set of tools for developing an Azure Search instance in Visual Studio, analogous to what SSDT is for SQL Server.

In an ideal world, these tools would allow me to define indexes, indexers, datasources, and all other components necessary for my search index. The tools would also include ability to publish my changes to the instance, either through Visual Studio itself or from a CI build in Release Management.

I think it would be valuable to expand the capabilities of suggesters. Right now, they're somewhat limited. I think it would be nice if they provided the flexibility of scoring profiles. The reason why is because sometimes, it might be nice to show the most recently added or viewed documents (i.e. Edm.DateTimeOffset) as suggestions. Other times, you may want to show the most popular, or most viewed, documents (i.e Edm.Int32). These are just two scenarios that I would like to cover with suggestions, but, I'm a bit limited.