DocumentationExperience Cloud KCS

Resolving Universal Editor access and configuration issues when AEM is the EDS content source

Last update: June 27, 2026

When Edge Delivery Services (EDS) uses AEM as its content source, authors don’t see expected metadata fields, block configuration values, template variations, or JSON data inside the Universal Editor. The cause is almost always an architectural or configuration mismatch: an EDS project supports only one primary content source, BYOM (Bring Your Own Model) models must explicitly expose metadata to the Universal Editor, dynamic field population requires a custom Universal Editor extension, and JSON or configuration data has to be intentionally exposed through the EDS repo, Structured Content, or DAM mappings. Confirming the authoring mode, enforcing the single-source rule, and exposing the required metadata and data restores the missing editor fields.

Description description

Issue: Universal Editor doesn’t surface metadata, block fields, or JSON data when AEM is the EDS content source

Description

When working with Edge Delivery Services (EDS) and the Universal Editor (UE), authors don’t see expected metadata fields, block configuration values, template variations, nor JSON data inside the editor. Pages fail to load correctly in UE, or authors can’t configure page-level metadata, dynamic fields, or block options. In other cases, customers attempt unsupported architectural patterns — such as mixing Universal Editor and document-based authoring within a single EDS project, or configuring multiple content sources within the same fstab.yaml. These misconfigurations cause inconsistent rendering, missing metadata, inability to use certain authoring interfaces, or blocks that fail to consume required inputs from AEM.

Environment:

  • Adobe Experience Manager as a Cloud Service (AEMaaCS)
  • AEM Managed Services
  • AEM as a Cloud Service — Sites
  • Edge Delivery Services (EDS)
  • Universal Editor

Issue/Symptoms:

  • Universal Editor loads, but metadata fields or block configuration fields don’t appear, with no error shown.
  • Blocks fail to render due to missing page-level or block-level metadata from BYOM.
  • Authors expect both document-based and UE authoring in one EDS project, but only one source is recognized.
  • Custom JSON or configuration data isn’t available inside the Universal Editor, even though the file exists in DAM or GitHub.
  • Dynamic dialog/dropdown options for blocks never populate in UE.

Root cause:

EDS and the Universal Editor follow a strict architectural model. A single EDS project has only one primary content source, BYOM models must explicitly expose metadata to the Universal Editor, dynamic field population requires custom Universal Editor extensions, and JSON or other configuration data must be intentionally exposed through the EDS repo, Structured Content, or DAM mappings. Misconfiguration of any of these areas results in missing metadata, inaccessible configuration data, or unsupported hybrid setups.

How to confirm

  1. Confirm which authoring mode the project uses — Universal Editor, document-based, or both — to establish whether Universal Editor is enabled and expected to work for the page in question. If it’s unclear, capture the exact URL being opened in UE.
  2. Review the fstab.yaml or project requirements to confirm the EDS project uses only one primary content source, and whether the setup attempts to mix AEM and document-based sources in one project.
  3. Confirm whether the page-level metadata needed for UE authoring is exposed via BYOM, including a base page-metadata model and any template-specific models. Confirm that template = page-type is stored in the page metadata if a template is required.

Resolution resolution

  1. Enforce the single-content-source rule. EDS supports one primary content source per project. If the project mixes sources — such as AEM and document-based authoring together — create two separate EDS sites and use CDN routing to direct traffic between them. Native hybrid UE plus document-based authoring in a single repo isn’t supported.

  2. Expose the metadata required for UE authoring through BYOM. Confirm a base page-metadata model exists, and define a template-specific metadata model where needed. Confirm AEM page properties expose the template metadata value the blocks expect.

  3. Expose custom JSON or configuration data based on whether it’s author-editable or static:

    • If the data is author-editable, use EDS Structured Content and define a schema.
    • If the data is static, store the JSON in the EDS repo, or in AEM DAM with explicit mappings.

Confirm the resulting endpoint URL is reachable so UE and the blocks can fetch the data.
4. Handle dynamic dropdown or field population correctly. EDS doesn’t support Granite UI datasources, so dynamic dropdown options can’t be loaded that way. Instead, use Universal Editor extensibility with custom fields and client-side API calls, which requires a UE extension to be implemented.
5. Verify template and block behavior for sites that need multiple page templates. Mark the relevant AEM pages as Use as Template, and set the template metadata (CSS class) for styling. Create a page from the template and confirm it carries the correct initial content and metadata.

Validation

  1. Open the page in the Universal Editor and confirm all expected metadata fields and block configuration fields are visible.
  2. Load the page on the .page domain and confirm dynamic metadata or JSON data renders into the page head.
  3. Confirm fetch() calls to JSON endpoints return the expected content.
  4. Confirm blocks using dynamic configuration render correctly after republishing.
recommendation-more-help
experience-cloud-kcs-help-kbarticles