Clean up SLO and cases docs

docs/en/observability/create-observability-connectors.asciidoc

@@ -1,7 +1,8 @@
 [[cases-external-connectors]]
 = Configure external connectors
 
-You can send cases to these third-party systems:
+If you are using an external incident management system, you can integrate Elastic Observability 
+cases with that system using _connectors_. These third-party systems are supported:
 
 * {sn-itsm}
 * {sn-sir}
@@ -64,7 +65,13 @@ To update an existing connector:
 
 [discrete]
 [[close-connector-observability]]
-== Close sent cases automatically
+== Sending and closing cases
+
+To send a case to an external system, click the **Push as <connector name> incident** button from the individual case page. 
+This information is not sent automatically. If you make further changes to the shared case fields, you should push the case again.
+
+If you close cases in your external incident management system, the cases will remain open in Elastic Observability until you close them 
+manually.
 
 To close cases when they are sent to an external system, select
-*Automatically close cases when pushing new incident to external system*.
+*Automatically close cases when pushing new incident to external system* when adding a connector to a case.

docs/en/observability/slo-create.asciidoc

@@ -35,18 +35,18 @@ The type of SLI to use depends on the location of your data:
 [[custom-kql-sli]]
 == Custom KQL
 
-Create an indicator based on any of your {es} indices or index patterns. You define two queries: one that yields the good events from your index, and one that yields the total events from your index. 
+Create an indicator based on any of your {es} indices or data views. You define two queries: one that yields the good events from your index, and one that yields the total events from your index. 
 
 *Example:* You can define a custom KQL indicator based on the `service-logs` with the *good query* defined as `nested.field.response.latency <= 100 and nested.field.env : “production”` and the *total query* defined as `nested.field.env : “production”`. 
 
 When defining a custom KQL SLI, set the following fields:
 
-* *Index* — The index or index pattern you want to base the SLI on. For example, `service-logs`.
+* *Index* — The data view or index pattern you want to base the SLI on. For example, `service-logs`.
 * *Timestamp field* — The timestamp field used by the index.
 * *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents.
 * *Good query* — The query yielding events that are considered good or successful. For example, `nested.field.response.latency <= 100 and nested.field.env : “production”`
 * *Total query* — The query yielding all events to take into account for computing the SLI. For example, `nested.field.env : “production”`.
-* *Partition by* — Create an SLO for each value of the field you enter. 
+* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.
 
 [discrete]
 [[custom-metric-sli]]
@@ -59,7 +59,7 @@ Create an indicator to define custom equations from metric fields in your indice
 When defining a custom metric SLI, set the following fields:
 
 * *Source*
-** *Index* — The index or index pattern you want to base the SLI on. For example, `my-service-*`.
+** *Index* — The data view or index pattern you want to base the SLI on. For example, `my-service-*`.
 ** *Timestamp field* — The timestamp field used by the index.
 ** *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents. For example, `'field.environment : "production" and service.name : "my-service"'`.
 * *Good events*
@@ -70,7 +70,7 @@ When defining a custom metric SLI, set the following fields:
 ** *Metric [A-Z]* — The field that is aggregated using the `sum` aggregation for total events. For example, `processor.processed`
 ** *Filter [A-Z]* — The filter to apply to the metric for total events. For example, `"processor.outcome: *"`
 ** *Equation* — The equation that calculates the total metric. For example, `A`.
-* *Partition by* — Create an SLO for each value of the field you enter. 
+* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.
 
 [discrete]
 [[histogram-metric-sli]]
@@ -85,7 +85,7 @@ When using a `range` aggregation, both the `from` and `to` thresholds are requir
 When defining a histogram metric SLI, set the following fields:
 
 * *Source*
-** *Index* — The index or index pattern you want to base the SLI on. For example, `my-service-*`.
+** *Index* — The data view or index pattern you want to base the SLI on. For example, `my-service-*`.
 ** *Timestamp field* — The timestamp field used by the index.
 ** *Query filter* — A KQL filter to specify relevant criteria by which to filter the index documents. For example, `field.environment : "production" and service.name : "my-service"`.
 * *Good events*
@@ -100,7 +100,7 @@ When defining a histogram metric SLI, set the following fields:
 ** *From* — (`range` aggregation only) The starting value of the range for total events. For example, `0`.
 ** *To* — (`range` aggregation only) The ending value of the range for total events. For example, `100`.
 ** *KQL filter* — The filter for total events. For example, `"processor.outcome : *"`.
-* *Partition by* — Create an SLO for each value of the field you enter. 
+* *Partition by* — The field used to partition the data based on the values of the specific field. For example, you could partition by the `url.domain` field, which would create individual SLOs for each value of the selected field.
 
 [discrete]
 [[apm-latency-and-availability-sli]]