Skip to main content

Hi everyone,

I’m working on an LWR Digital Experience site and would like to pass a value as a path parameter

rather than as a query parameter. 

 

Instead of using the URL format:

https://test.com/test?QP=testRecord

I would like to use the following URL format:

https://test.com/test/testRecord

In this case, testRecord would be a dynamic path parameter.

 

I’ve tried configuring a custom route in Experience Builder, but I’m getting the message:

“Include only alphanumeric characters and hyphens.”

 

Any guidance or examples would be greatly appreciated.

Thank you! 

 

#Experience  #Digital Experience  #LWR

4 个回答
  1. 9月7日 20:17

    Hi @Shanika Nishani

     

    Experience Builder doesn't support dynamic path segments for custom pages. The "alphanumeric and hyphens only" validation you're hitting is by design the path field only accepts a literal, static string, not a placeholder token like {param} or :param. 

     

    Why this happens 

    The routes.json dynamic-route syntax you may have seen in Salesforce docs applies to pro-code LWR apps built with the standalone LWR framework/CLI (outside Experience Cloud entirely) not to LWR sites built in Experience Builder. In Experience Builder, you don't get direct access to routes.json; the platform generates routing config from what you set in the Pages panel, and that UI only accepts static, hyphenated paths. 

    The one built-in exception 

    Object/Record Detail pages do support a dynamic segment automatically e.g. /s/product/{recordId} or /s/product/{urlName} but only because that's a special out-of-the-box "Object Page" type tied to a Supported Object via the UI API. You don't configure that path pattern yourself; it comes for free with that page type. It won't generalize to an arbitrary custom page. 

    Practical workarounds 

    1. Query parameters (supported, no workaround needed) /test?QP=testRecord, read via CurrentPageReference in your LWC. This is the intended mechanism for passing dynamic values to a custom LWR page.
    2. Edge/CDN URL rewrite if your custom domain sits behind a CDN or reverse proxy you control (Cloudflare, Akamai, CloudFront, etc.), add a rewrite rule that maps /test/testRecord → /test?QP=testRecord before the request hits Salesforce. The browser URL stays pretty; Salesforce still only ever sees the query-param version. This is the most common way teams get "clean URLs" on Experience Cloud today.
    3. Object Page pattern, generalized if what you actually want is "detail page keyed by a record's URL-friendly name," consider modeling it as a real Object Page against a Supported Object rather than a generic custom page then you inherit the dynamic-path behavior natively instead of fighting the custom-page path field.
    4. True pro-code LWR if dynamic path routing is a hard requirement, that's a signal this isn't a fit for an Experience Builder-managed site at all; a decoupled/headless approach (LWR OSS app, or a separate front-end calling Salesforce APIs) gives you full routes.json control, at the cost of losing Experience Builder's drag-and-drop admin experience.

    Given the trade-offs, most teams end up on option 2 (CDN rewrite) since it needs zero Salesforce-side changes and keeps admins working in Experience Builder normally. If you want to go that route, worth confirming first whether you're using Salesforce's own domain/CDN or a custom DNS setup in front of it that determines whether you even have a layer available to add the rewrite rule. 

     

    I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

0/9000