Automatically created managed properties in SharePoint Online (and on-prem) are created from their corresponding site columns always as text (details at https://docs.microsoft.com/en-us/sharepoint/technical-reference/automatically-created-managed-properties-in-sharepoint). Basically, these managed properties are being created as textual representations of the values of their corresponding site columns. The problem with these approach is that we can only make free search queries with these managed properties even if the corresponding site column is of type Date or Decimal for example. With this approach, more intelligent queries according to the site column data type as range queries cannot be performed. Here are some examples of queries cannot be performed with these automatically created managed properties:

Date based query example #1: SiteColumnNameOWSDATE>1/1/2018
Date based query example #2: SiteColumnNameOWSDATE>1/1/2017 AND SiteColumnNameOWSDATE<1/1/2018

Number based query example #1: SiteColumnNameOWSNMBR>1000
Number based query example #2: SiteColumnNameOWSNMBR>500 AND SiteColumnNameOWSNMBR<1000

If we need to make queries with the same type as the corresponding site columns, the current solution is to use Refinable managed properties (there is a limited number of available Refinable managed properties, depending on its type). There are here very limiting numbers like 10 RefinableDecimal managed properties or 20 RefinableDate managed properties.

I understand that there have to be limitations on the amount of freedom each tenant or farm can have to change the search schema (because of stability/scalability/performance) but I also believe that having automatically created managed properties to be generated with the same data type or an inferred type from their corresponding site columns, would make SharePoint Search a much better solution without the current limitations since automatically created managed properties would be created with the data type developers and users want to query data and would allow both users to find the information they want and developers to build better search based solutions, making more intelligent search queries and taking full advantage of the queries that each data type supports (imagine a database with a column of type number where we cannot make a range query like column > 0 or column < 100 for instance, it just doesn't make sense).

Here are some advantages if automatically generated managed properties are created with the same data type or an inferred type from their corresponding site columns and not always as text:

• Users and developers would be able to make all types of search queries the data type of the managed property supports

• Assuming users want to search the information they create and developers want to build solution to search data users create, virtually there would be almost no need to map automatically created crawled properties with existing Refinable managed properties because automatically created managed properties would have the type users want to query

• This change would not bring more load on search and would prevent developers to need to create new managed properties or manually map their crawled properties with Refinable managed properties because the managed properties they need are automatically created by SharePoint

• The number of Refinable managed properties could be reduced since developers resort to these managed properties because automatically created managed properties don't have the data type they need

If changing the existing managed properties can lead to compability issues, instead of changing the existing managed properties, I ask you to add additional automatically generated managed properties that are created with the same data type or an inferred type from their corresponding site columns.

*English follows Japanese

■Title(件名)：
SharePoint アプリでのリストの検索結果の並び順について
Regarding the search results sort order for lists in Sharepoint app

■Description(内容):
リストで検索した場合、PC やモバイル端末のブラウザーでは、[リストの設定] から既定のビューの編集画面で [並べ替え] で指定した並び順にもとづいて検索結果が表示される。
しかしながら、SharePoint アプリの場合、検索結果に該当するアイテムが、初期の設定である ID 順で表示される動作となる。
この点について、PC などと表示順が異なるとアイテムの確認に手間がかかるため、PC などの動作と同様に、指定した並び順にもとづいて検索結果を表示させることができるようにしてほしい。
When searching using a list, the search results are shown accordingly to what has been set in the Sort option in the List Settings for browsers on the PC and mobile devices.
However for the Sharepoint app, search results are shown according to the default setting, which is ID.
This ends up in using up time to check what results have been returned as the order is different from what is shown on the PC and mobile devices. Thus I hope that the search results will be shown in the chosen sort order, exactly in the same way as how it is done on the PC and mobile devices.

*English follows Japanese

■Title(件名)：
Microsoft Stream の動画タイトルおよび詳細の全文を対象に部分一致検索の機能を拡充してほしい。
Add ability to search for partial matches in titles and descriptions of videos on Microsoft Stream

■Description(内容):
Microsoft Stream の現在の動画の検索では、タイトル及び詳細に文字制限があるため検索できない部分がある。
タイトル及び詳細の全文対象に部分一致検索ができると検索できる動画が増えて利便性が高くなるので、全文対象に部分一致検索の機能を拡充をしてほしい。
The current video search function on Microsoft Stream has a restriction on characters in titles and details that it can search, so there are things which cannot be searched for.
If the search would return partial matches from the full text of title and details fields then the number of results would be increased and therefore the function would be more convenient, so I would like this function to be improved to allow the return of partial matches from the entirety of text on videos.

I have separate default views for a modern-experience library and the modern-experience document sets contained in the library, as the library contains folders (document sets) only, and the document sets contain documents only.
If you open a document set in the library, the view changes automatically to the default view of the document set, as expected.
If you open a document set via search results, the view remains in the library's folder-based default view, and thus the document set appears to be empty. You then have to change the view to the document set's default view to be able to see the documents.

If the default (modern) view of a library has Group By columns and the groupings are collapsed by default:
Search results are also collapsed. If you try to expand a group in the search results, the following error scenarios occur:
* Nothing happens: the group tries to expand ("loading" message), but then remains collapsed. If you try to expand the group again, an error occurs.
* The group expands, but if you try to adjust the width of a column, the group collapses. If you try to expand the group again, an error occurs.
* The group expands, but if you expand a different group, an error occurs, or the groups collapse and an error occurs if you try to expand one of them.

This happens in more than one of our company sites. Tested in Windows 10 using Chrome, Firefox and Internet Explorer.

Error code: -2146232832