What’s a Login Discovery page?

November 10, 2025

What’s a Login Discovery page?

It’s the identifier-first screen for an Experience Cloud site - the page that asks for something like an email or phone first, then routes the user to the right login flow. It’s distinct from the org-level My Domain login page. 🔎

Context (why we even touched metadata) 📚

We needed to brand an Experience Cloud Login Discovery experience. Standard help content didn’t clearly show a UI path for login discovery page branding on our site, and developer docs point to the Network Branding meta data type (which represents branding for Experience Cloud login pages). So we started with metadata. Help articles from Hokoriam and Medium.

What we did (exactly) 🛠️

  • Our site was already activated and published; Login Discovery was enabled.
  • We exported NetworkBranding, edited it in VS Code, and tried to deploy.
  • We mistakenly removed the file named <DeveloperName>.networkBranding (thinking a folder could hold the image). That file is a Salesforce-generated binary container paired with the XML file; deleting or replacing it can cause deploy failures with a generic internal error. After this, our deploy failed with an ErrorId. ❌
  • The surprise: Later, when we reopened Experience Workspace → Administration → Login & Registration, the declarative discovery-branding controls (logo + colors) were visible. We didn’t expect that at all-it felt like Salesforce quietly slid a new switch under our chair while we weren’t looking. We set them there and published. (No extra retrieve in between.) 🎛️🎉

So why did the controls appear? 🤔

We can’t claim a single root cause. Two plausible, non-exclusive explanations that align with Salesforce documentation and field experience:

(A) Asset/feature-gate detection. Some discovery/login controls only surface when certain conditions are met (for example: Experience site active/published, Login Discovery configured, and a branding asset recognized for the site). Salesforce’s docs confirm login/discovery is configurable in Workspaces and that branding for Experience sites is a first-class concept-though the exact surface area can vary by template/runtime.

(B) Under-documented capability. Salesforce’s public docs clearly describe My Domain login branding (org-level), and they document NetworkBranding as metadata for Experience login pages, but discovery-page UI controls for Experience sites aren’t consistently highlighted in help articles. Many teams reasonably start with metadata.

Important distinctions (so nobody mixes apples and meteorites) 🧭

  • My Domain login/discovery (org-level) is branded from My Domain → Branding and configured with a Login Discovery handler-that’s separate from Experience site branding.
  • Experience Cloud site branding for login pages is represented by the NetworkBranding metadata (and by controls in Workspaces for many templates).

What we recommend (cautious, based on what we validated) ✅

If you see discovery-branding controls in Workspaces: Use them. Set logo/colors in Experience Workspace → Administration → Login & Registration, then Publish.

If you don’t see those controls yet (and your site uses hosted login + Login Discovery): - Consider the metadata route using NetworkBranding, which Salesforce documents as the metadata for Experience login branding. Keep the two artifacts together: - <DeveloperName>.networkBranding (Salesforce-generated binary, no extension) - <DeveloperName>.networkBranding-meta.xml (colors/settings) Deleting or replacing the binary with a folder is a common cause of deploy failures. 🧩 - As a sanity check, verify that Login/Discovery is configured for the site and that you’re working on the Experience site, not My Domain.

Optional (for release hygiene) 🧼

After you set branding in the UI and Publish, retrieve NetworkBranding so your repo includes the binary + XML pair. That’s a standard Metadata API workflow and makes it easy to deploy the same look to other sandboxes or prod later.

Troubleshooting crib sheet 🩺

  • Deploy error with an internal ErrorId on NetworkBranding: often indicates the binary container is missing/mismatched or the component can’t be parsed. Ensure the file <DeveloperName>.networkBranding exists next to the -meta.xml.
  • Can’t find the UI for discovery branding: confirm you’re on an Experience site (not just My Domain), that Login Discovery is configured for the site, and that your template/runtime supports branding in Workspaces.

Takeaway 🌟

Discovery-page branding for Experience sites is achievable with clicks or code, but the path isn’t spelled out in one tidy article. If the UI is present, use it and publish. If it isn’t, NetworkBranding metadata is the documented lever-just keep the binary file and XML together.

Follow us for more updates:

https://www.linkedin.com/company/lenticular-solutions