[Rules] Rules Overview page

src/content/changelogs/rules.yaml

@@ -5,6 +5,18 @@ productLink: "/rules/"
 productArea: Application performance
 productAreaLink: /fundamentals/reference/changelog/performance/
 entries:
+  - publish_date: "2025-01-09"
+    title: New Rules Overview page
+    description: |-
+      The new **Rules Overview** interface consolidates Cloudflare Rules products into a single, intuitive page, simplifying navigation and rule management. Key features include:
+
+      - **Unified interface**: Manage all rules in one place — no more navigating through multiple menu tabs.
+      - **Search across rules**: Quickly locate specific rules.
+      - **Clear rule order**: View and manage rules by their execution sequence for streamlined configuration.
+      - **Enhanced visibility**: Instantly view the filter (conditions) and action (outcome) for every rule.
+      - **Faster debugging**: Use Trace directly from the zone-level interface for simple, quick troubleshooting.
+
+      The new page is available in the Cloudflare dashboard at **Rules** > **Overview**.
   - publish_date: "2024-12-11"
     title: Snippets support in the Cloudflare provider for Terraform
     description: |-

src/content/docs/api-shield/security/jwt-validation/transform-rules.mdx

@@ -7,7 +7,6 @@ sidebar:
 head:
   - tag: title
     content: Enhance Transform Rules with JWT claims
-
 ---
 
 You can forward information from a [JSON Web Token (JWT)](/api-shield/security/jwt-validation/) to the origin in a header by creating [Transform Rules](/rules/transform/) using claims that Cloudflare has verified via the JSON Web Token.
@@ -16,21 +15,19 @@ Claims are available through the `http.request.jwt.claims` firewall fields.
 
 For example, the following expression will extract the user claim from a token processed by the Token Configuration with `TOKEN_CONFIGURATION_ID`:
 
-```json
-
+```txt
 lookup_json_string(http.request.jwt.claims["<TOKEN_CONFIGURATION_ID>"][0], "claim_name")
-
 ```
 
-​​Refer to [Configure JWT Validation](/api-shield/security/jwt-validation/configure/) for more information about creating a Token Configuration.
+Refer to [Configure JWT Validation](/api-shield/security/jwt-validation/configure/) for more information about creating a Token Configuration.
 
 ## Create a Transform Rule
 
 As an example, to send the `x-send-jwt-claim-user` request header to the origin, you must create a Transform Rule:
 
 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain.
-2. Go to **Rules** > **Transform Rules**.
-3. Select **Modify Request Header** > **Create rule**.
+2. Go to **Rules** > **Overview**.
+3. Next to **Request Header Transform Rules**, select **Create rule**.
 4. Enter a rule name and a filter expression, if applicable.
 5. Choose **Set dynamic**.
 6. Set the header name to `x-send-jwt-claim-user`.

src/content/docs/cache/how-to/cache-rules/create-dashboard.mdx

@@ -9,8 +9,8 @@ head:
 ---
 
 1.  Log in to the [Cloudflare dashboard](https://dash.cloudflare.com/) and select your account and domain.
-2.  Go to **Caching** > **Cache Rules**.
-3.  To create a new empty rule, select **Create rule**. To duplicate an existing rule, select the three dots next to it > **Duplicate**.
+2.  Go to **Rules** > **Overview**.
+3.  Next to **Cache Rules**, select **Create rule**.
 4.  (Optional) Select one of the rule templates that address common use cases. Then, review and adjust the proposed rule configuration.
 5.  Enter a descriptive name for the rule in **Rule name**.
 6.  Under **When incoming requests match**, select **All incoming requests** if you want the rule to apply to all traffic or **Custom filter expression** if you want the rule to only apply to traffic matching the custom expression.

src/content/docs/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/provider-guides/salesforce-commerce-cloud.mdx

@@ -5,16 +5,21 @@ head:
   - tag: title
     content: Salesforce Commerce Cloud | Provider guides
 description: Learn how to configure your Enterprise zone with Salesforce Commerce Cloud.
-
 ---
 
-import { Details, Render } from "~/components"
+import { Details, Render } from "~/components";
 
-<Render file="provider-guide-intro" params={{ one: "Salesforce Commerce Cloud" }} />
+<Render
+	file="provider-guide-intro"
+	params={{ one: "Salesforce Commerce Cloud" }}
+/>
 
 ## Benefits
 
-<Render file="provider-guide-benefits" params={{ one: "Salesforce Commerce Cloud" }} />
+<Render
+	file="provider-guide-benefits"
+	params={{ one: "Salesforce Commerce Cloud" }}
+/>
 
 ## How it works
 
@@ -24,7 +29,7 @@ For additional detail about how traffic routes when O2O is enabled, refer to [Ho
 
 To enable O2O requires the following:
 
-1. Your SFCC environment must be configured as an "SFCC Proxy Zone". If you currently have an "SFCC Legacy Zone", you cannot enable O2O. More details on the different types of SFCC configurations can be found [here](https://help.salesforce.com/s/articleView?id=cc.b2c_ecdn_proxy_zone_faq.htm\&type=5).
+1. Your SFCC environment must be configured as an "SFCC Proxy Zone". If you currently have an "SFCC Legacy Zone", you cannot enable O2O. More details on the different types of SFCC configurations can be found [here](https://help.salesforce.com/s/articleView?id=cc.b2c_ecdn_proxy_zone_faq.htm&type=5).
 2. Your own Cloudflare zone on an Enterprise plan.
 
 If you meet the above requirements, O2O can then be enabled per hostname. To enable O2O for a specific hostname within your Cloudflare zone, [create](/dns/manage-dns-records/how-to/create-dns-records/#create-dns-records) a Proxied `CNAME` DNS record with a target of the `CNAME` provided by SFCC Business Manager, which is the dashboard used by SFCC customers to configure their storefront environment.
@@ -41,7 +46,6 @@ The `CNAME` provided by SFCC Business Manager will resemble `commcloud.prod-abcd
 
 For O2O to be configured properly, make sure your Proxied DNS record targets your SFCC CNAME **directly**. Do not indirectly target the SFCC CNAME by targeting another Proxied DNS record in your Cloudflare zone which targets the SFCC CNAME.
 
-
 <Details header="Correct configuration">
 
 For example, if the hostnames routing traffic to SFCC are `www.example.com` and `preview.example.com`, the following is a **correct** configuration in your Cloudflare zone:
@@ -51,10 +55,8 @@ For example, if the hostnames routing traffic to SFCC are `www.example.com` and
 | `CNAME` | `www.example.com`     | `commcloud.prod-abcd-example-com.cc-ecdn.net` | Proxied      |
 | `CNAME` | `preview.example.com` | `commcloud.prod-abcd-example-com.cc-ecdn.net` | Proxied      |
 
-
 </Details>
 
-
 <Details header="Incorrect configuration">
 
 And, the following is an **incorrect** configuration because `preview.example.com` indirectly targets the SFCC CNAME via the `www.example.com` Proxied DNS record, which means O2O will not be properly enabled for hostname `preview.example.com`:
@@ -64,7 +66,6 @@ And, the following is an **incorrect** configuration because `preview.example.co
 | `CNAME` | `www.example.com`     | `commcloud.prod-abcd-example-com.cc-ecdn.net` | Proxied      |
 | `CNAME` | `preview.example.com` | `www.example.com`                             | Proxied      |
 
-
 </Details>
 
 ## Product compatibility
@@ -73,7 +74,10 @@ And, the following is an **incorrect** configuration because `preview.example.co
 
 ## Additional support
 
-<Render file="provider-guide-help" params={{ one: "Salesforce Commerce Cloud" }} />
+<Render
+	file="provider-guide-help"
+	params={{ one: "Salesforce Commerce Cloud" }}
+/>
 
 ### Resolving SSL errors using Cloudflare Managed Certificates
 
@@ -84,25 +88,25 @@ If you do have a `CAA` record, verify that it permits SSL certificates to be iss
 ### Best practice Zone-level configuration
 
 1. Set **Minimum TLS version** to **TLS 1.2**
-   1. Navigate to **SSL/TLS > Edge Certificates**, scroll down the page to find **Minimum TLS Version**, and set it to *TLS 1.2*. This setting applies to every Proxied DNS record in your Zone.
+   1. Navigate to **SSL/TLS > Edge Certificates**, scroll down the page to find **Minimum TLS Version**, and set it to _TLS 1.2_. This setting applies to every Proxied DNS record in your Zone.
 2. Match the **Security Level** set in **SFCC Business Manager**
-   1. *Option 1: Zone-level* - Navigate to **Security > Settings**, find **Security Level** and set **Security Level** to match what is configured in **SFCC Business Manager**. This setting applies to every Proxied DNS record in your Cloudflare zone.
-   2. *Option 2: Per Proxied DNS record* - If the **Security Level** differs between the Proxied DNS records targeting your SFCC environment and other Proxied DNS records in your Cloudflare zone, use a **Configuration Rule** to set the **Security Level** specifically for the Proxied DNS records targeting your SFCC environment. For example:
-      1. Create a new **Configuration Rule** by navigating to **Rules > Configuration Rules** and click **Create rule**:
+   1. _Option 1: Zone-level_ - Navigate to **Security > Settings**, find **Security Level** and set **Security Level** to match what is configured in **SFCC Business Manager**. This setting applies to every Proxied DNS record in your Cloudflare zone.
+   2. _Option 2: Per Proxied DNS record_ - If the **Security Level** differs between the Proxied DNS records targeting your SFCC environment and other Proxied DNS records in your Cloudflare zone, use a **Configuration Rule** to set the **Security Level** specifically for the Proxied DNS records targeting your SFCC environment. For example:
+      1. Create a new **Configuration Rule** by navigating to **Rules** > **Overview** and selecting **Create rule** next to **Configuration Rules**:
          1. **Rule name:** `Match Security Level on SFCC hostnames`
-         2. **Field:** *Hostname*
-         3. **Operator:** *is in* (this will match against multiple hostnames specified in the **Value** field)
+         2. **Field:** _Hostname_
+         3. **Operator:** _is in_ (this will match against multiple hostnames specified in the **Value** field)
          4. **Value:** `www.example.com` `dev.example.com`
          5. Scroll down to **Security Level** and click **+ Add**
-            1. **Select Security Level:** *Medium* (this should match the **Security Level** set in **SFCC Business Manager**)
+            1. **Select Security Level:** _Medium_ (this should match the **Security Level** set in **SFCC Business Manager**)
          6. Scroll to the bottom of the page and click **Deploy**
 3. Disable **Browser Integrity Check**
-   1. *Option 1: Zone-level* - Navigate to **Security > Settings**, find **Browser Integrity Check** and toggle it off to disable it. This setting applies to every Proxied DNS record in your Cloudflare zone.
-   2. *Option 2: Per Proxied DNS record* - If you want to keep **Browser Integrity Check** enabled for other Proxied DNS records in your Cloudflare zone but want to disable it on Proxied DNS records targeting your SFCC environment, keep the Zone-level **Browser Integrity Check** feature enabled and use a **Configuration Rule** to disable **Browser Integrity Check** specifically for the hostnames targeting your SFCC environment. For example:
-      1. Create a new **Configuration Rule** by navigating to **Rules > Configuration Rules** and click **Create rule**:
+   1. _Option 1: Zone-level_ - Navigate to **Security > Settings**, find **Browser Integrity Check** and toggle it off to disable it. This setting applies to every Proxied DNS record in your Cloudflare zone.
+   2. _Option 2: Per Proxied DNS record_ - If you want to keep **Browser Integrity Check** enabled for other Proxied DNS records in your Cloudflare zone but want to disable it on Proxied DNS records targeting your SFCC environment, keep the Zone-level **Browser Integrity Check** feature enabled and use a **Configuration Rule** to disable **Browser Integrity Check** specifically for the hostnames targeting your SFCC environment. For example:
+      1. Create a new **Configuration Rule** by navigating to **Rules** > **Overview** and selecting **Create rule** next to **Configuration Rules**:
          1. **Rule name:** `Disable Browser Integrity Check on SFCC hostnames`
-         2. **Field:** *Hostname*
-         3. **Operator:** *is in* (this will match against multiple hostnames specified in the **Value** field)
+         2. **Field:** _Hostname_
+         3. **Operator:** _is in_ (this will match against multiple hostnames specified in the **Value** field)
          4. **Value:** `www.example.com` `dev.example.com`
          5. Scroll down to **Browser Integrity Check** and click the **+ Add** button:
             1. Set the toggle to **Off** (a grey X will be displayed)
@@ -111,13 +115,13 @@ If you do have a `CAA` record, verify that it permits SSL certificates to be iss
    1. Your SFCC environment, also called a **Realm**, will contain one to many SFCC Proxy Zones, which is where caching will always occur. In the corresponding SFCC Proxy Zone for your domain, SFCC performs their own cache optimization, so it is recommended to bypass the cache on the Proxied DNS records in your Cloudflare zone which target your SFCC environment to prevent a "double caching" scenario. This can be accomplished with a **Cache Rule**.
    2. If the **Cache Rule** is not created, caching will occur in both your Cloudflare zone and your corresponding SFCC Proxy Zone, which can cause issues if and when the cache is invalidated or purged in your SFCC environment.
       1. Additional information on caching in your SFCC environment can be found in [SFCC's Content Cache Documentation](https://developer.salesforce.com/docs/commerce/b2c-commerce/guide/b2c-content-cache.html)
-   3. Create a new **Cache Rule** by navigating to **Rules > Cache Rules** and click **Create rule**:
+   3. Create a new **Cache Rule** by navigating to **Rules** > **Overview** and selecting **Create rule** next to **Cache Rules**:
       1. **Rule name:** `Bypass cache on SFCC hostnames`
-      2. **Field:** *Hostname*
-      3. **Operator:** *is in* (this will match against multiple hostnames specified in the **Value** field)
+      2. **Field:** _Hostname_
+      3. **Operator:** _is in_ (this will match against multiple hostnames specified in the **Value** field)
       4. **Value:** `www.example.com` `dev.example.com`
-      5. **Cache eligibility:** Select **Bypass cache**
-      6. Scroll to the bottom of the page and click **Deploy**
-5. *Optional* - Upload your Custom Certificate from **SFCC Business Manager** to your Cloudflare zone
+      5. **Cache eligibility:** Select **Bypass cache**.
+      6. Scroll to the bottom of the page and select **Deploy**.
+5. _Optional_ - Upload your Custom Certificate from **SFCC Business Manager** to your Cloudflare zone:
    1. The Custom Certificate you uploaded via **SFCC Business Manager** or **SFCC CDN-API**, which exists within your corresponding SFCC Proxy Zone, will terminate TLS connections for your SFCC storefront hostnames. Because of that, it is optional if you want to upload the same Custom Certificate to your own Cloudflare zone. Doing so will allow Cloudflare users with specific roles in your Cloudflare account to receive expiration notifications for your Custom Certificates. Please read [renew custom certificates](/ssl/edge-certificates/custom-certificates/renewing/#renew-custom-certificates) for further details.
    2. Additionally, since you now have your own Cloudflare zone, you have access to Cloudflare's various edge certificate products which means you could have more than one certificate covering the same SANs. In that scenario, a certificate priority process occurs to determine which certificate to serve at the Cloudflare edge. If you find your SFCC storefront hostnames are presenting a different certificate compared to what you uploaded via **SFCC Business Manager** or **SFCC CDN-API**, the certificate priority process is likely the reason. Please read [certificate priority](/ssl/reference/certificate-and-hostname-priority/#certificate-deployment) for further details.

src/content/docs/firewall/troubleshooting/required-changes-to-enable-url-normalization.mdx

@@ -24,7 +24,7 @@ Cloudflare did not enable URL normalization automatically for zones that would b
 
 ## Why URL normalization is important
 
-Cloudflare strongly recommends that you enable **Normalize incoming URLs** in **Rules** > **URL Normalization** to strengthen your zone's security posture. Not doing so leaves your zone at greater risk of a successful attack. Malicious parties could craft the URL in a way that the rules are not accounting for.
+Cloudflare strongly recommends that you enable **Normalize incoming URLs** in **Rules** > **Overview** > **URL Normalization** to strengthen your zone's security posture. Not doing so leaves your zone at greater risk of a successful attack. Malicious parties could craft the URL in a way that the rules are not accounting for.
 
 For example, a firewall rule with an expression such as `http.request.uri.path contains "/login"` could be bypassed if the malicious actor has encoded the `l` character as `%6C`. In this scenario, and with URL normalization disabled, traffic would not be matched by the firewall rule.
 
@@ -55,7 +55,7 @@ Before enabling URL normalization, you should review the affected firewall rules
 
 ### 2. Enable URL normalization
 
-Once you have updated the affected firewall rules, enable URL normalization in **Rules** > **URL Normalization**.
+Once you have updated the affected firewall rules, enable URL normalization in **Rules** > **Overview** > **URL Normalization**.
 
 A Cloudflare user must have the [Firewall role](/fundamentals/setup/manage-members/roles/) or one of the Administrator roles to access URL normalization settings in the dashboard.