[SaaS] Review scenarios for hostname priority (#21893)

* Add GlossaryTooltip for proxied and zone terminology

* Remove second possibility and call out 1014 error

* Update second bullet to mention Orange-to-Orange

* Disambiguate: Customer1 zone is not a SaaS provider

* Edit to refer back to what had been explained in the intro

* Further disambiguate Customer1 is not a SaaS provider

* Apply suggestion from PM review: clarify example refers to new CH

* Apply suggestion from code review

Co-authored-by: marciocloudflare <[email protected]>

* Apply suggestion from CSUP: further clarify legacy SaaS provider

---------

Co-authored-by: marciocloudflare <[email protected]>

Author: 2 people

src/content/docs/ssl/reference/certificate-and-hostname-priority.mdx

@@ -8,6 +8,8 @@ description: Learn about how Cloudflare decides which certificate and associated
 
 ---
 
+import { GlossaryTooltip } from "~/components";
+
 When a new certificate is created, Cloudflare first deploys the certificate and then serves it.
 
 ***
@@ -52,7 +54,7 @@ Cloudflare uses the following order to determine the certificate and settings us
 
 ## Hostname priority
 
-When multiple proxied DNS records exist for a hostname, in multiple zones — usually due to Cloudflare for SaaS — only one record will control the zone settings and associated origin server.
+When multiple <GlossaryTooltip term="proxy status">proxied DNS records</GlossaryTooltip> exist for a hostname, in multiple <GlossaryTooltip term="zone">zones</GlossaryTooltip> — usually due to [Cloudflare for SaaS](/cloudflare-for-platforms/cloudflare-for-saas/) — only one record will control the zone settings and associated origin server.
 
 Cloudflare determines this priority in the following order, assuming each record exists and is proxied (orange-clouded):
 
@@ -75,9 +77,9 @@ If a hostname resource record is not proxied (gray-clouded) for a zone on Cloudf
 
 Customer1 uses Cloudflare as authoritative DNS for the zone `shop.example.com`. Customer2 is a SaaS provider that creates and successfully [verifies the new custom hostname](/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-validation/) `shop.example.com`. Afterward, traffic starts routing over Customer2's zone:
 
-* If Customer1 wants to regain control of their zone, Customer1 contacts Customer2 and requests them to delete the custom hostname record. Another possibility is to stop proxying (gray-cloud) the record.
-* If Customer1 is already proxying a new custom hostname for `www.example.com`, Customer2 creates and verifies `www.example.com` so traffic starts routing over Customer2's zone. Since this new custom hostname is the last one validated, the new custom hostname on Customer1's zone enters a *moved* status.
-* If Customer1 is already proxying a legacy custom hostname for `www.example.com` and Customer2 creates and verifies a new wildcard custom hostname for `*.example.com`, traffic is routed to Customer1's zone while the `www.example.com` CNAME points to Customer1.
+* If Customer1 wants to regain control of their zone, Customer1 contacts Customer2 and requests them to delete the custom hostname record. Customer1 should make sure to have their record target updated to something other than the SaaS provider target, otherwise Customer1 would get a [`1014` error](/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/#error-1014-cname-cross-user-banned).
+* If Customer1 already has a proxied record for `www.example.com` when Customer2 creates and verifies a new custom hostname `www.example.com`, [Orange-to-Orange](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/how-it-works/) applies.
+* If Customer1 already has a proxied record for `www.example.com` in a legacy custom hostname setup (with another SaaS provider, Customer3) and Customer2 creates and verifies a new wildcard custom hostname for `*.example.com`, legacy custom hostname on Customer3 platform takes precedence due to exact hostname match.
 
 #### Scenario 2