diff --git a/docs/ocis/adr/0020-file-search-query-language.md b/docs/ocis/adr/0020-file-search-query-language.md
index e897c6b25c..d5156057f7 100644
--- a/docs/ocis/adr/0020-file-search-query-language.md
+++ b/docs/ocis/adr/0020-file-search-query-language.md
@@ -1,15 +1,15 @@
 ---
 title: "20. File Search Query Language"
-date: 2022-03-18T09:00:00+01:00
+date: 2022-06-23T09:00:00+01:00
 weight: 20
 geekdocRepo: https://github.com/owncloud/ocis
 geekdocEditPath: edit/master/docs/ocis/adr
 geekdocFilePath: 0020-file-search-query-language.md
 ---
 
-* Status: proposed
-* Deciders: @butonic, @micbar, @dragotin, @C0rby
-* Date: 2022-03-18
+* Status: accepted
+* Deciders: @butonic, @micbar, @dragotin, @C0rby, @kulmann, @felix-schwarz, @JammingBen
+* Date: 2023-06-23
 
 ## Context and Problem Statement
 
@@ -28,6 +28,7 @@ From the users perspective, the interface to search is just a single form field
 
 ## Considered Options
 
+* [KQL - Keyword Query Language](#keyword-query-language)
 * [Simple Query](#simplified-query)
 * [Lucene Query Language](#lucene-query-language)
 * [Solr Query Language](#solr-query-language)
@@ -35,19 +36,31 @@ From the users perspective, the interface to search is just a single form field
 
 ## Decision Outcome
 
-Chosen option: [Simple Query](#simplified-query), because it is a suitable MVP.
+Chosen option: [KQL - Keyword Query Language](#keyword-query-language), because it enables advanced search across all platforms.
 
 ### Positive Consequences
 
-* We can do a quick implementation
+* We can use the same query language in all clients
 
 ### Negative consequences
 
-* We cannot specify terms or other search criteria
-* We will need to find a good point in time to use a query language before we start working around it
+* We need to build and maintain a backend connector
 
 ## Pros and Cons of the Options
 
+### Keyword Query Language
+
+The Keyword Query Language (KQL) is used by Microsoft Share Point and other Microsoft Services. It uses very simple query elements, property restrictions and operators.
+
+* Good, because we can fulfill all our current needs
+* Good, because it is very similar to the used query language in iOS
+* Good, because it supports date time keywords like "today", "this week" and more
+* Good, because it can be easily extended to use "shortcuts" for eg. document types like `:presentation` which combine multiple mime types.
+* Good, because it is successfully implemented and used in similar use cases
+* Good, because it gives our clients the freedom to always use the same query language across all platforms
+* Good, because Microsoft Graph API is using it, we will have an easy transition in the future
+* Bad, because we need to build and maintain a connector to different search backends (bleve, elasticsearch or others)
+
 ### Simplified Query
 
 Implement a very simple search approach: Return all files which contain at least one of the keywords in their name, path, alias or selected metadata.
@@ -90,6 +103,7 @@ Elasticsearch provides a full Query DSL (Domain Specific Language) based on JSON
 
 * [Search API](0018-file-search-api.md)
 * [Search Indexing](0019-file-search-index.md)
+* [KQL](https://learn.microsoft.com/en-us/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference)
 * [Apache Lucene](https://lucene.apache.org/)
 * [Apache Solr](https://solr.apache.org/)
 * [Elastic Search](https://solr.apache.org/)