[Cases][Quality] Consolidate and refactor case docs

deploy-manage/autoscaling/autoscaling-in-ece-and-ech.md

@@ -78,7 +78,7 @@ On a highly available deployment, autoscaling events are always applied to insta
 ## Notifications[ec-autoscaling-notifications]
 In the event that a data tier or machine learning node scales up to its maximum possible size, you’ll receive an email, and a notice also appears on the deployment overview page prompting you to adjust your autoscaling settings to ensure optimal performance.
 
-In {{ece}} deployments, a warning is also issued in the ECE `service-constructor` logs with the field `labels.autoscaling_notification_type` and a value of `data-tier-at-limit` (for a fully scaled data tier) or `ml-tier-at-limit` (for a fully scaled machine learning node). The warning is indexed in the `logging-and-metrics` deployment, so you can use that event to [configure an email notification](../../explore-analyze/alerts-cases/watcher.md).
+In {{ece}} deployments, a warning is also issued in the ECE `service-constructor` logs with the field `labels.autoscaling_notification_type` and a value of `data-tier-at-limit` (for a fully scaled data tier) or `ml-tier-at-limit` (for a fully scaled machine learning node). The warning is indexed in the `logging-and-metrics` deployment, so you can use that event to [configure an email notification](../../explore-analyze/alerting/watcher.md).
 
 ## Restrictions and limitations[ec-autoscaling-restrictions]
 

deploy-manage/deploy/cloud-enterprise/edit-stack-settings-elasticsearch.md

@@ -43,7 +43,7 @@ To add or edit {{es}} user settings:
 $$$ece-change-user-settings-examples$$$
 ## Example: enable email notifications [ece_enable_email_notifications_from_gmail]
 
-To enable email notifications in your {{es}} cluster, you need to configure an email account and related settings. For complete instructions, refer to [Configuring email accounts](/explore-analyze/alerts-cases/watcher/actions-email.md#configuring-email).
+To enable email notifications in your {{es}} cluster, you need to configure an email account and related settings. For complete instructions, refer to [Configuring email accounts](/explore-analyze/alerting/watcher/actions-email.md#configuring-email).
 
 ```yaml
 xpack.notification.email.account:

deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md

@@ -15,7 +15,7 @@ The instructions in this section describe how to connect the operator and manage
 These instructions have been tested with Istio 1.24.3. Older or newer versions of Istio might require additional configuration steps not documented here.
 
 ::::{warning}
-Some {{stack}} features such as [{{kib}} alerting and actions](/explore-analyze/alerts-cases.md) rely on the {{es}} API keys feature which requires TLS to be enabled at the application level. If you want to use these features, you should not disable the self-signed certificate on the {{es}} resource and enable `PERMISSIVE` mode for the {{es}} service through a `DestinationRule` or `PeerAuthentication` resource. Strict mTLS mode is currently not compatible with {{stack}} features requiring TLS to be enabled for the {{es}} HTTP layer.
+Some {{stack}} features such as [{{kib}} alerting and actions](/explore-analyze/alerting.md) rely on the {{es}} API keys feature which requires TLS to be enabled at the application level. If you want to use these features, you should not disable the self-signed certificate on the {{es}} resource and enable `PERMISSIVE` mode for the {{es}} service through a `DestinationRule` or `PeerAuthentication` resource. Strict mTLS mode is currently not compatible with {{stack}} features requiring TLS to be enabled for the {{es}} HTTP layer.
 ::::
 
 

deploy-manage/deploy/deployment-comparison.md

@@ -41,7 +41,7 @@ For more details about feature availability in {{serverless-short}}, refer to []
 | Feature/capability | Fully self-managed, ECE, ECK | ECH | {{serverless-short}} |
 |-------------------|-------------------------------|---------|----------------------|
 | [Deployment health monitoring](/deploy-manage/monitor.md) | AutoOps or monitoring cluster | AutoOps or monitoring cluster | Managed by Elastic |
-| [Alerting](/explore-analyze/alerts-cases.md) | Watcher or {{kib}} alerts | Watcher or {{kib}} alerts | Alerts ([why?](/explore-analyze/alerts-cases.md#watcher)) |
+| [Alerting](/explore-analyze/alerting.md) | Watcher or {{kib}} alerts | Watcher or {{kib}} alerts | Alerts ([why?](/explore-analyze/alerting.md#watcher)) |
 
 ## Data lifecycle
 

deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md

@@ -101,7 +101,7 @@ This table compares Elasticsearch capabilities between {{ech}} deployments and S
 | [**Search applications**](/solutions/elasticsearch-solution-project/search-applications.md) | - UI and APIs <br>- Maintenance mode (beta) | - API-only <br>- Maintenance mode (beta) | UI not available in Serverless |
 | **Shard management** | User-configurable | Managed by Elastic | No manual shard allocation in Serverless |
 | [**Synonyms**](/solutions/search/full-text/search-with-synonyms.md) | - Index time synonyms <br>- File-based synonyms <br>- Synonyms API | Synonyms API only (does not support index-time or file-based synonyms) | |
-| [**Watcher**](/explore-analyze/alerts-cases/watcher.md) | ✅ | ❌ | Use **Kibana Alerts** instead, which provides rich integrations across use cases |
+| [**Watcher**](/explore-analyze/alerting/watcher.md) | ✅ | ❌ | Use **Kibana Alerts** instead, which provides rich integrations across use cases |
 | **Web crawler** | ❌ (Managed Elastic Crawler discontinued with Enterprise Search in 9.0) | Self-managed only | Use [**self-managed crawler**](https://github.com/elastic/crawler) |
 
 ^1^ $$$footnote-1$$$ In {{serverless-short}}, Elastic ensures data durability by storing indexed data in an [object store](https://www.elastic.co/blog/elastic-serverless-architecture) rather than local replicas. Writes are batched over a 200ms window to ensure durability while optimizing performance and cost, which means that single-document indexing can appear slower than in {{ech}}. However, this design makes {{serverless-short}} more scalable and resilient to high indexing loads without relying on in-cluster replication for fault tolerance. Because of a higher baseline write latency, {{serverless-short}} indexing can be scaled by increasing concurrent indexing clients.

deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md

@@ -91,7 +91,7 @@ Changing the default throttle period is not possible. You can specify a throttle
 
 Watcher comes preconfigured with a directly usable email account provided by Elastic. However, this account can’t be reconfigured and is subject to some limitations. For more information on the limits of the Elastic mail server, check the [cloud email service limits](/deploy-manage/deploy/elastic-cloud/tools-apis.md#email-service-limits).
 
-Alternatively, a custom mail server can be configured as described in [Configuring a custom mail server](../../../explore-analyze/alerts-cases/watcher/enable-watcher.md#watcher-custom-mail-server)
+Alternatively, a custom mail server can be configured as described in [Configuring a custom mail server](../../../explore-analyze/alerting/watcher/enable-watcher.md#watcher-custom-mail-server)
 
 
 ## Private connectivity and SSO to {{kib}} URLs [ec-restrictions-network-security-kibana-sso]
@@ -108,7 +108,7 @@ Currently you can’t use SSO to login directly from {{ecloud}} into {{kib}} end
 ## {{kib}} [ec-restrictions-kibana]
 
 * The maximum size of a single {{kib}} instance is 8GB. This means, {{kib}} instances can be scaled up to 8GB before they are scaled out. For example, when creating a deployment with a {{kib}} instance of size 16GB, then 2x8GB instances are created. If you face performance issues with {{kib}} PNG or PDF reports, the recommendations are to create multiple, smaller dashboards to export the data, or to use a third party browser extension for exporting the dashboard in the format you need.
-* Running an external {{kib}} in parallel to {{ecloud}}’s {{kib}} instances may cause errors, for example [`Unable to decrypt attribute`](../../../explore-analyze/alerts-cases/alerts/alerting-common-issues.md#rule-cannot-decrypt-api-key), due to a mismatched [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#security-encrypted-saved-objects-settings) as {{ecloud}} does not [allow users to set](edit-stack-settings.md) nor expose this value. While workarounds are possible, this is not officially supported nor generally recommended.
+* Running an external {{kib}} in parallel to {{ecloud}}’s {{kib}} instances may cause errors, for example [`Unable to decrypt attribute`](../../../explore-analyze/alerting/alerts/alerting-common-issues.md#rule-cannot-decrypt-api-key), due to a mismatched [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#security-encrypted-saved-objects-settings) as {{ecloud}} does not [allow users to set](edit-stack-settings.md) nor expose this value. While workarounds are possible, this is not officially supported nor generally recommended.
 * Workflows using the `elasticsearch.bulk` step might mishandle bulk operations in Elastic Cloud Hosted. Bulk action metadata (such as `index`, `create`, `update`, or `delete`) can be interpreted as document data, which might cause unexpected behavior for bulk operations beyond basic indexing. The workaround is to use a generic Elasticsearch request action in the workflow to call the Bulk API directly instead of using the `elasticsearch.bulk` step. For more information, refer to [Generic request actions](https://www.elastic.co/docs/explore-analyze/workflows/steps/elasticsearch#generic-request-actions). This issue is fixed in Serverless deployments.
 
 

deploy-manage/deploy/elastic-cloud/tools-apis.md

@@ -101,7 +101,7 @@ serverless: unavailable
 
 ## Elastic Cloud email service
 
-{{ecloud}} provides a built-in email service used by the preconfigured [email connector](kibana://reference/connectors-kibana/email-action-type.md), available in both {{ech}} deployments and {{serverless-full}} projects. This service can be used to send [alert](/explore-analyze/alerts-cases/alerts.md) notifications and is also supported in {{ech}} by [Watcher](/explore-analyze/alerts-cases/watcher/enable-watcher.md).
+{{ecloud}} provides a built-in email service used by the preconfigured [email connector](kibana://reference/connectors-kibana/email-action-type.md), available in both {{ech}} deployments and {{serverless-full}} projects. This service can be used to send [alert](/explore-analyze/alerting/alerts.md) notifications and is also supported in {{ech}} by [Watcher](/explore-analyze/alerting/watcher/enable-watcher.md).
 
 ### Email service limits
 

deploy-manage/deploy/self-managed/bootstrap-checks.md

@@ -187,7 +187,7 @@
 
 If you use {{watcher}} and have chosen to encrypt sensitive data (by setting `xpack.watcher.encrypt_sensitive_data` to `true`), you must also place a key in the secure settings store.
 
-To pass this bootstrap check, you must set the `xpack.watcher.encryption_key` on each node in the cluster. For more information, see [Encrypting sensitive data in Watcher](../../../explore-analyze/alerts-cases/watcher/encrypting-data.md).
+To pass this bootstrap check, you must set the `xpack.watcher.encryption_key` on each node in the cluster. For more information, see [Encrypting sensitive data in Watcher](../../../explore-analyze/alerting/watcher/encrypting-data.md).
 :::
 
 :::{dropdown} PKI realm check

deploy-manage/manage-connectors.md

@@ -23,7 +23,7 @@ This page is about {{kib}} connectors that integrate with services like generati
 
 ## Required permissions [_required_permissions_2]
 
-Access to connectors is granted based on your privileges to alerting-enabled features. For more information, go to [Security](../explore-analyze/alerts-cases/alerts/alerting-setup.md#alerting-security).
+Access to connectors is granted based on your privileges to alerting-enabled features. For more information, go to [Security](../explore-analyze/alerting/alerts/alerting-setup.md#alerting-security).
 
 ## Connector networking configuration [_connector_networking_configuration]
 
@@ -91,6 +91,6 @@ If a connector is missing sensitive information after the import, a **Fix** butt
 
 ## Monitoring connectors [monitoring-connectors]
 
-You can query the [Event log index](/explore-analyze/alerts-cases/alerts/event-log-index.md) to gather information on connector successes and failures.
+You can query the [Event log index](/explore-analyze/alerting/alerts/event-log-index.md) to gather information on connector successes and failures.
 
 If you're using {{stack}}, then you can also use the [Task Manager health API](/deploy-manage/monitor/kibana-task-manager-health-monitoring.md) to monitor connector performance. However, if connectors fail to run, they will report as successful to Task Manager. The failure stats will not accurately depict connector failures.

deploy-manage/monitor/kibana-task-manager-health-monitoring.md

@@ -114,7 +114,7 @@ The Runtime `status` indicates whether task executions have exceeded any of the
 ::::{important}
 Some tasks (such as [connectors](../manage-connectors.md)) will incorrectly report their status as successful even if the task failed. The runtime and workload block will return data about success and failures and will not take this into consideration.
 
-To get a better sense of action failures, refer to the [Event log index](../../explore-analyze/alerts-cases/alerts/event-log-index.md) for more accurate context into failures and successes.
+To get a better sense of action failures, refer to the [Event log index](../../explore-analyze/alerting/alerts/event-log-index.md) for more accurate context into failures and successes.
 
 ::::
 

deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md

@@ -15,7 +15,7 @@ products:
 
 # Stack monitoring alerts [kibana-alerts]
 
-The {{stack}} {{monitor-features}} provide [Alerting rules](../../../explore-analyze/alerts-cases/alerts.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
+The {{stack}} {{monitor-features}} provide [Alerting rules](../../../explore-analyze/alerting/alerts.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
 
 :::{image} /deploy-manage/images/kibana-monitoring-kibana-alerting-notification.png
 :alt: {{kib}} alerting notifications in {{stack-monitor-app}}

deploy-manage/monitor/monitoring-data/elasticsearch-metrics.md

@@ -31,7 +31,7 @@
 To view the key metrics that indicate the overall health of an {{es}} cluster, click **Overview** in the {{es}} section. Anything that needs your attention is highlighted in yellow or red.
 
 ::::{tip}
-Conditions that require your attention are listed at the top of the Clusters page. You can also set up watches to alert you when the status of your cluster changes. To learn how, see [Watching the status of an {{es}} cluster](../../../explore-analyze/alerts-cases/watcher/watch-cluster-status.md).
+Conditions that require your attention are listed at the top of the Clusters page. You can also set up watches to alert you when the status of your cluster changes. To learn how, see [Watching the status of an {{es}} cluster](../../../explore-analyze/alerting/watcher/watch-cluster-status.md).
 ::::
 
 

deploy-manage/monitor/monitoring-data/integrations-server-page.md

@@ -29,7 +29,7 @@ products:
 
 2. Adjust the time period for the visualizations as needed.
 
-3. From this page you can also [create alerts](/explore-analyze/alerts-cases/alerts/create-manage-rules.md) to be triggered when the {{integrations-server}} metrics meet a defined set of conditions. 
+3. From this page you can also [create alerts](/explore-analyze/alerting/alerts/create-manage-rules.md) to be triggered when the {{integrations-server}} metrics meet a defined set of conditions. 
 
 **To view metrics for a specific {{integrations-server}} instance:**
 
@@ -41,4 +41,4 @@ products:
 
 1. Adjust the time period for the visualizations as needed.
 
-1. As with the **APM server overview** page, you can also [create alerts](/explore-analyze/alerts-cases/alerts/create-manage-rules.md) to be triggered when the instance metrics meet a defined set of conditions. 
+1. As with the **APM server overview** page, you can also [create alerts](/explore-analyze/alerting/alerts/create-manage-rules.md) to be triggered when the instance metrics meet a defined set of conditions. 

deploy-manage/production-guidance/kibana-alerting-production-considerations.md

@@ -33,7 +33,7 @@
 
 You can address such issues by tweaking the [Task Manager settings](kibana://reference/configuration-reference/task-manager-settings.md) or scaling the deployment to better suit your use case.
 
-For detailed guidance, see [Alerting Troubleshooting](../../explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md).
+For detailed guidance, see [Alerting Troubleshooting](../../explore-analyze/alerting/alerts/alerting-troubleshooting.md).
 
 ::::
 

deploy-manage/production-guidance/kibana-in-production-environments.md

@@ -19,7 +19,7 @@ How you deploy {{kib}} largely depends on your use case. If you are the only use
 
 ## Scalability
 
-With the introduction of new capabilities such as [{{kib}} Alerting](/explore-analyze/alerts-cases.md) and the [Detection Rules](/solutions/security/detect-and-alert.md) engine, critical components for [Observability](/solutions/observability.md) and [Security](/solutions/security.md) solutions, the scalability factors have evolved significantly.
+With the introduction of new capabilities such as [{{kib}} Alerting](/explore-analyze/alerting.md) and the [Detection Rules](/solutions/security/detect-and-alert.md) engine, critical components for [Observability](/solutions/observability.md) and [Security](/solutions/security.md) solutions, the scalability factors have evolved significantly.
 
 Now, Kibana’s resource requirements extend beyond user activity. The system must also handle workloads generated by automated processes, such as scheduled alerts, background detection rules, and other periodic tasks. These operations are managed by [{{kib}} Task Manager](./kibana-task-manager-scaling-considerations.md), which is responsible for scheduling, executing, and coordinating all background tasks.
 

deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md

@@ -14,7 +14,7 @@ products:
 
 # {{kib}} task manager: performance and scaling guide [task-manager-production-considerations]
 
-{{kib}} Task Manager is leveraged by features such as [alerting](/explore-analyze/alerts-cases/alerts.md), [actions](/explore-analyze/alerts-cases/alerts.md#rules-actions), and [reporting](/explore-analyze/report-and-share.md) to run mission critical work as persistent background tasks. These background tasks distribute work across multiple {{kib}} instances. This has three major benefits:
+{{kib}} Task Manager is leveraged by features such as [alerting](/explore-analyze/alerting/alerts.md), [actions](/explore-analyze/alerting/alerts.md#rules-actions), and [reporting](/explore-analyze/report-and-share.md) to run mission critical work as persistent background tasks. These background tasks distribute work across multiple {{kib}} instances. This has three major benefits:
 
 - **Persistence**: All task state and scheduling is stored in {{es}}, so if you restart {{kib}}, tasks will pick up where they left off.
 - **Scaling**: Multiple {{kib}} instances can read from and update the same task queue in {{es}}, allowing the work load to be distributed across instances. If a {{kib}} instance no longer has capacity to run tasks, you can increase capacity by adding additional {{kib}} instances.

deploy-manage/toc.yml

@@ -555,9 +555,6 @@ toc:
               - file: users-roles/cloud-enterprise-orchestrator/saml.md
           - file: users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md
       - file: users-roles/serverless-custom-roles.md
-        children:
-          - title: "Control access at the document and field level"
-            crosslink: docs-content://deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md
       - file: users-roles/cluster-or-deployment-auth.md
         children:
           - file: users-roles/cluster-or-deployment-auth/quickstart.md