From eb9de95267fba03a6f8fa6d14dfb2a3080236c79 Mon Sep 17 00:00:00 2001
From: "nastasha.solomon" <nastasha.solomon@elastic.co>
Date: Tue, 7 May 2024 21:50:32 -0400
Subject: [PATCH] First draft

---
 docs/detections/rules-ui-create.asciidoc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc
index bf8e964672..a0d3b7d109 100644
--- a/docs/detections/rules-ui-create.asciidoc
+++ b/docs/detections/rules-ui-create.asciidoc
@@ -311,7 +311,7 @@ NOTE: Rules that use aggregating queries might create duplicate alerts. This can
 [float]
 [[esql-non-agg-query]]
 ===== Non-aggregating query 
-Non-aggregating queries doesn't use `STATS...BY` functions and doesn't aggregate source event data. Alerts generated by an {esql} rule with a non-aggregating query only contain the fields returned by the query.
+Non-aggregating queries don't use `STATS...BY` functions and don't aggregate source event data. Alerts generated by an ES|QL rule with a non-aggregating query contain the fields returned by the query and all fields in the source event document.
 
 Here is an example non-aggregating query:
 [source,esql]
@@ -376,6 +376,8 @@ NOTE: The `max_signals` default value is 100. You can modify it using the <<rule
 
 - When writing an aggregating query, use the {ref}/esql-commands.html#esql-stats-by[`STATS...BY`] command with fields that you want to search and filter for after alerts are created. For example, using the `host.name`, `user.name`, `process.name` fields with the `BY` operator of the `STATS...BY` command returns these fields in alert documents, and allows you to search and filter for them from the Alerts table. 
 
+- If your {esql} query creates new fields that aren’t in the query’s source index, they can be added to the rule’s <<rule-ui-advanced-params,custom highlighted fields>>.
+
 [float]
 [[esql-rule-limitations]]
 ==== {esql} rule limitations  
@@ -383,7 +385,6 @@ NOTE: The `max_signals` default value is 100. You can modify it using the <<rule
 The {esql} rule has the following limitations:
 
 - If your {esql} query creates new fields that aren’t part of the ECS schema, they won’t be mapped to the alerts index and you can't search or filter for them from the Alerts table. As a workaround, create <<runtime-fields,runtime fields>>. 
-- If your {esql} query creates new fields that aren’t in the query’s source index, they can’t be added to the rule’s <<rule-ui-advanced-params,custom highlighted fields>>.
 
 [float]
 [[rule-ui-basic-params]]