Merge pull request #484 from mulesoft/W-12143600-2.x-update-to-root-gr

Update main to root

Author: glenn-rodgers-sf

modules/ROOT/pages/access-client-app-id-task.adoc

@@ -7,7 +7,7 @@ As the owner of a xref:exchange::to-request-access.adoc[registered client applic
 
 You are required to provide the client ID and client secret credentials depending on the policies applied to that API. For example, if the API owner has applied the Client ID Enforcement policy, you must provide your application's client ID and, optionally, its client secret to access the API.
 
-You must have the Organization Administrator privileges of the main organization, or must be the owner of the client application to access the credentials.  
+You must have the Organization Administrator privileges of the root organization, or must be the owner of the client application to access the credentials.  
 
 To obtain the credentials of a client application:
 

modules/ROOT/pages/configure-multiple-credential-providers.adoc

@@ -32,7 +32,7 @@ If no external IdPs are enabled, Access Manager acts as the default authorizatio
 
 To better understand how to implement multiple external client providers, imagine a company named "Good Weather" that uses meteorology to forecast changing weather. Good Weather collects quantitative data about the current state of the atmosphere at a given place and, using meteorology, predicts how that current state will change over time.
 
-Good Weather has several sub-organizations running under the main organization. These sub-organizations exist based on the functions they perform, for example, Engineering and Forecasting. The Forecasting department researches and collects recent meterological data from various sources. This data is then consumed by various client applications. While the Engineering department maintains the applications that host the forecasting research data.
+Good Weather has several sub-organizations running under the root organization. These sub-organizations exist based on the functions they perform, for example, Engineering and Forecasting. The Forecasting department researches and collects recent meterological data from various sources. This data is then consumed by various client applications. While the Engineering department maintains the applications that host the forecasting research data.
 
 Because Good Weather must ensure that its weather-forecasting data is accurate and secure, the weather APIs are accessed only by employees of the Forecasting department. Good Weather also wants to ensure that the production APIs are the single source of truth at all times.
 
@@ -77,7 +77,7 @@ You can then reassign the appropriate external client provider for that API.
 +
 After you assign an external client provider to an API, you can return to using the default native Anypoint Platform client provider by removing every provider from the environment in which the API belongs.
 * If you remove a client provider from an environment, all existing APIs and client applications using that client provider continue to work.
-* If you delete a client provider from the main organization, all existing APIs and client applications using that client provider default to the native Anypoint Platform client provider.
+* If you delete a client provider from the root organization, all existing APIs and client applications using that client provider default to the native Anypoint Platform client provider.
 +
 Even though contracts remain intact, policies that authorize against that provider fail because the configuration is deleted.
 * An API created in an environment with an assigned external client provider always uses the external client provider, not the native Anypoint Platform client provider. The following describes one workaround:
@@ -95,7 +95,7 @@ Based on your role and the needs of your organization, you might perform the fol
 | Task | Role | Where to Perform | Notes
 | Assign multiple IdPs, including a default, to an environment. | Business Group Administrator| Access Management | Using multiple IdPs provides flexibility to choose an IdP in API configuration inside API Manager, which can be useful when multiple teams are using the same environment for building APIs, but still want to use separate IdPs. This also helps in use cases when separate API instances are created for internal and external consumers, and separate IdPs based on a consumer is required. 
 | Receive notification about possible interruption to API consumers before changing IdP configuration. | Business Group Administrator | Access Management | None
-// | Main Organization Administrator | Change the default IdP across all environments and business groups. | Access Management | Resetting the default IdP updates all environments across all business groups to a selected IDP, without affecting existing client applications. This way, when a new IdP is created for the organization, all environments are updated with just one change.
+// | Root Organization Administrator | Change the default IdP across all environments and business groups. | Access Management | Resetting the default IdP updates all environments across all business groups to a selected IDP, without affecting existing client applications. This way, when a new IdP is created for the organization, all environments are updated with just one change.
 | Review to which client provider an application belongs on the client administrator page to be able to differentiate between different applications with the same name. | API Manager Administrator| Access Management | None
 | Configure an API in API Manager to automatically map to a default IdP configured by the business group administrator. The owner can also select a different IdP, if available. | API owner | API manager | None
 | When promoting or importing an API from one environment to another, specify an IdP from the target environment. | API owner | API manager | If there is just one (default) IdP specified for the target environment, it is automatically assigned to the API. 

modules/ROOT/pages/migrate-client-apps.adoc

@@ -60,7 +60,7 @@ curl --location --request POST 'https://anypoint.mulesoft.com/exchange/api/v1/or
     "redirectUri": []
 }'
 ----
-. Replace the `orgId` parameter with the ID of your main organization and the content of the body with the appropriate application <<properties,properties>>. 
+. Replace the `orgId` parameter with the ID of your root organization and the content of the body with the appropriate application <<properties,properties>>. 
 . Run this command at the command prompt.
 
 [[migrate_with_external]]

modules/ROOT/pages/remove-client-app-latest-task.adoc

@@ -3,7 +3,7 @@ ifndef::env-site,env-github[]
 include::_attributes.adoc[]
 endif::[]
 
-As the Organization Administrator of the main organization, you can revoke or delete a contract that is providing an application access to your API. When you revoke a contract, you can restore the contract at any time. 
+As the Organization Administrator of the root organization, you can revoke or delete a contract that is providing an application access to your API. When you revoke a contract, you can restore the contract at any time. 
 
 Deleting a contract deletes the approved contract from Anypoint Exchange. Revoking a contract blocks the client application from accessing the API. When you revoke a contract, you can either restore or delete the contract anytime. Before you delete a contract, you must first revoke it. 
 

modules/ROOT/pages/view-delete-alerts-task.adoc

@@ -3,7 +3,7 @@ ifndef::env-site,env-github[]
 include::_attributes.adoc[]
 endif::[]
 
-If you have been granted the *Organization Administrators* role for the main organization, you can view a list of alerts that are generated for APIs in the API Manager.
+If you have been granted the *Organization Administrators* role for the root organization, you can view a list of alerts that are generated for APIs in the API Manager.
 
 Before you can view and delete alerts, ensure that you have: