fix more annotations

Author: shainaraskas

deploy-manage/cloud-organization/billing/manage-subscription.md

@@ -41,10 +41,10 @@ To change your subscription level:
 
 ### Feature usage notifications [ec_feature_usage_notifications]
 
-:::{applies_to}
+```{applies_to}
 deployment:
   ess: all
-:::
+```
 
 If you try to change your subscription to a lower level, but you are using features that belong either to your current level or to a higher one, you need to make some changes before you can proceed, as described in **Review required feature changes**.
 

deploy-manage/users-roles.md

@@ -30,11 +30,11 @@ Preventing unauthorized access is only one element of a complete security strate
 
 ## Cloud organization level
 
-:::{applies_to}
+```{applies_to}
 deployment:
   ess: all
 :serverless: all
-:::
+```
 
 If you’re using {{ecloud}}, then you can perform the following tasks to control access to your Cloud organization, your Cloud Hosted deployments, and your Cloud Serverless projects:
 
@@ -52,8 +52,9 @@ For {{ech}} deployments, you can configure SSO at the organization level, the de
 
 ## Orchestrator level
 
-:::{applies_to}
-:ece: all
+```{applies_to}
+deployment:
+  ece: all
 :::
 
 Control access to your {{ece}} [orchestrator](/deploy-manage/deploy/cloud-enterprise/deploy-an-orchestrator.md) and deployments. 
@@ -79,23 +80,23 @@ You can't manage users and roles for {{eck}} clusters at the orchestrator level.
 
 ## Project level
 
-:::{applies_to}
+```{applies_to}
 :serverless: all
-:::
+```
 
 As an extension of the [predefined instance access roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#ec_instance_access_roles) offered for {{serverless-short}} projects, you can create custom roles at the project level to provide more granular control, and provide users with only the access they need within specific projects.
 
 [Learn more about custom roles for {{serverless-full}} projects](/deploy-manage/users-roles/serverless-custom-roles.md).
 
 ## Cluster or deployment level
 
-:::{applies_to}
+```{applies_to}
 deployment:
   ece: all
   ess: all
   eck: all
   self: all
-:::
+```
 
 Set up authentication and authorization at the cluster or deployment level, and learn about the underlying security technologies that Elasticsearch uses to authenticate and authorize requests internally and across services.
 

explore-analyze/find-and-organize/data-views.md

@@ -101,10 +101,10 @@ Temporary {{data-sources}} are not available in the **Management** menu.
 
 
 ### Use {{data-sources}} with rolled up data [rollup-data-view]
-::::{applies_to}
-:serverless: unavailable
-:stack: deprecated
-::::
+```{applies_to}
+serverless: unavailable
+stack: deprecated
+```
 
 ::::{admonition}
 :class: warning
@@ -123,10 +123,10 @@ For an example, refer to [Create and visualize rolled up data](/manage-data/life
 
 
 ### Use {{data-sources}} with {{ccs}} [management-cross-cluster-search]
-::::{applies_to}
-:serverless: unavailable
-:stack: ga
-::::
+```{applies_to}
+serverless: unavailable
+stack: ga
+```
 
 If your {{es}} clusters are configured for [{{ccs}}](../../solutions/search/cross-cluster-search.md), you can create a {{data-source}} to search across the clusters of your choosing. Specify data streams, indices, and aliases in a remote cluster using the following syntax:
 

explore-analyze/find-and-organize/saved-objects.md

@@ -126,9 +126,9 @@ However, saved objects can only be imported into the same version, a newer minor
 | 7.8.1 | 9.0.0 | No |
 
 ## Saved Object IDs [saved-object-ids]
-::::{applies_to}
-:stack:
-::::
+```{applies_to}
+stack:
+```
 
 In the past, many saved object types could have the same ID in different [spaces](/deploy-manage/manage-spaces.md). For example, if you copied dashboard "123" from the one space to another space, the second dashboard would also have an ID of "123". While the saved object ID is not something that users would interact with directly, many aspects of {{kib}} rely on it, notably URLs. If you have a "deep link" URL to a saved dashboard, that URL includes the saved object ID.