Core Components, Dialogs, and Policies

Learn how modern AEM component delivery combines Core Components, cq:dialog, policies, style systems, and responsive layout.

Last reviewed: June 2026

·AEM 6.5AEM as a Cloud Service
✅
Quick Understanding: Modern AEM components are not just HTL files. They are authoring contracts built from Core Components, dialogs, policies, style rules, and layout behavior.

🔍 What Is It?

This topic connects the most important authoring concepts around components:

  • →Core Components as Adobe's maintained baseline
  • →Custom Components for project-specific behavior
  • →cq:dialog for author input
  • →Policies for template-level governance
  • →Style System for controlled visual variants
  • →Responsive Grid / Layout Container for page composition

Together they define how reusable and safe a component really is.

🎯 Why Do We Need It?

Projects fail when they focus only on rendering:

  • →authors need clear dialogs
  • →template authors need reusable policies
  • →designers need constrained styling options
  • →upgrade paths improve when teams extend Core Components instead of rebuilding everything

This is where developer productivity and author trust meet.

🏗️ What Happens in Real Projects?

A campaign team may use the Core Teaser Component with a project-specific Sling Model extension, a policy that limits allowed styles, and a style system offering only approved variants like "highlight" or "compact". Authors see a clean dialog, while frontend teams keep governance intact.

⚙️ How It Works

Modern flow:

  1. Pick Core Component reuse when possible
  2. Add custom logic only where business needs differ
  3. Expose author inputs through cq:dialog fields
  4. Apply policies at template level for allowed components and defaults
  5. Use Style System for safe variants instead of one-off CSS hacks
  6. Render inside responsive containers so authoring behavior stays predictable

💻 Example

Modern component contract — How authoring, governance, and rendering fit together.

text
Template policy
  -> allows Teaser + Carousel + Promo Banner
  -> default style = "brand-default"

Author opens dialog
  -> enters heading, image, CTA

Component rendering
  -> Sling Model prepares data
  -> HTL renders markup
  -> Style System adds approved variant class

Result
  -> reusable component with governed authoring choices

🤔 Common Confusions

❓ Are dialogs and policies the same thing?

No. Dialogs define per-instance author input. Policies define template-level rules and defaults shared by many component instances.

❓ Should new projects still build everything from scratch?

Usually no. Start from Core Components and extend thoughtfully. Full custom builds increase maintenance cost without guaranteed value.

🚨 Common Production Issues

A shared policy change breaks multiple templates because governance updates were treated like harmless authoring edits.

A dialog saves values but rendering fails because Sling Model expectations and dialog field names drifted apart.

Responsive layout behaves inconsistently across templates because teams mixed legacy container patterns with modern policy-driven authoring.

✅ Best Practices

Use Core Components first, custom components second.

Keep dialogs simple and aligned with actual business language.

Treat policy changes as cross-template release-impacting changes.

🏛️ Architect's Note

Senior Architect's Perspective

The most maintainable AEM programs optimize for authoring safety and upgradeability, not just initial rendering speed. Core Components plus disciplined dialogs and policies give teams a better long-term platform than a library of fragile custom widgets.

💬 Frequently Asked Questions

What is the difference between Design Dialog and policies?

Design Dialog is an older pattern. In modern AEM, editable-template policies are the preferred governance mechanism.

Where should style variants live?

Use Style System and approved frontend contracts instead of creating ad hoc author-controlled CSS classes.

🎯 Key Takeaways

1Core Components, dialogs, policies, and style rules form one component contract
2Policies govern reuse across templates; dialogs capture instance data
3Modern AEM authoring favors Core Components plus constrained extension

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these AEM references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide AEM learning path

Browse the full AEM topic collection and learning order on SplashRide.

AEM Interview Prep

Practice AEM interview questions and scenario-based answers.

AEM Developer Career Path

This AEM developer career path explains how to become an AEM developer through JCR, Sling, HTL, client libraries, Dispatcher, Cloud Service delivery, project depth, and interview-ready enterprise implementation skills.

Drupal Developer Career Path

A practical route through Drupal content modeling, site building, theming, modules, configuration management, APIs, performance, deployment discipline, and interview preparation.

AEM Components Explained: Dialogs, HTL, Sling Models, and Core Components

Learn AEM components with component nodes, dialogs, HTL, Sling Models, Core Components, authoring, inheritance, and real project patterns.

Editable Templates

Learn how Editable Templates replaced static templates in AEM and how they give template authors control over page structure without developer involvement.