AEM Sites Business Practitioner Expert cheat sheet

AEM runs on a Java stack (Apache Sling + Jackrabbit Oak JCR) and is deployed as a single Quickstart JAR or via the AEM as a Cloud Service model.

The content repository is hierarchical: /content holds pages, /apps holds code and components, /conf holds context-aware configurations, /etc is legacy, and /var holds runtime data.

Sling resolves a request URL to a resource and then to a script/component; the resource type plus selectors plus extension determine which script renders.

The OSGi framework manages bundles; services and components are registered and injected via OSGi, not directly instantiated.

Author tier is for content creation; Publish tier serves public traffic. Dispatcher (a reverse proxy/cache) sits in front of Publish.

AEM as a Cloud Service separates code (Cloud Manager pipeline) from content (content packages), and uses environment-specific config in /conf or Cloud Manager config pipelines.

Replication agents move content from Author to Publish; the default is a transport-based agent configured per environment.

Editable templates and core components are the modern foundation; static templates and foundation components are legacy.

The Granite platform provides the UI shell, user management, and the touch UI on top of Sling and Oak.

The Sites console lists pages in a tree; the page editor is used for in-context editing of components.

Layout mode defines the responsive grid; Edit mode edits component content; Preview mode renders without authoring chrome.

The component dialog is defined by the component's cq:dialog (touch UI) node; fields map to JCR properties.

Multi-site management uses blueprints and live copies; rollout configurations push blueprint changes to live copies.

Launches let authors stage content changes and publish them later; a launch is promoted to make changes live.

Versioning creates a snapshot of a page; authors can compare versions and restore a prior version.

The page properties dialog holds metadata, navigation settings, and advanced tab values such as template and vanity URLs.

The Assets side panel in the page editor allows inserting and referencing DAM assets directly into components.

The content tree and rail (Components, Assets, Content Tree) are the primary authoring tools in the touch UI.

A component is defined by a resource type under /apps; its rendering script can be HTL, JSP, or a servlet.

HTL (Sling Templates) uses data-sly-* attributes; it is preferred over JSP for new components.

The proxy component pattern inherits from a core component and overrides only what is needed; sling:resourceSuperType points to the base.

Editable templates define the structure and allowed components via policies; policies live under /conf.

The component policy mapping controls which components are allowed in a template's parsys/container.

Client libraries (clientlibs) are defined with cq:ClientLibraryFolder and categories; they bundle CSS/JS and are included via data-sly-call or the page component.

The responsive grid uses the Layout Container (or parsys) and breakpoints defined in the template policy.

AEM core components are extensible, accessible, and versioned; they are the recommended building blocks for new sites.

Sling Models map resource properties to Java objects and are commonly used in component logic.

The DAM stores assets under /content/dam; each asset has a metadata node (jcr:content/metadata).

Renditions are generated versions of an asset (e.g., thumbnail, web rendition); the original is the source.

Metadata schemas define which metadata fields appear on assets; they are configured per folder or globally.

Smart Tags and Smart Cropping use Adobe Sensei; they are configured via processing profiles.

Processing profiles apply to folders and control renditions, smart tagging, and metadata.

Content Fragments are structured content (model-driven) reusable across channels; Experience Fragments are reusable page sections.

The Content Fragment Model defines fields and is used to author fragments; fragments can be delivered via the JSON API.

Experience Fragments can be exported to Adobe Target and used in other AEM sites.

Asset collections and shared links support reuse and distribution; the Assets API supports programmatic access.

A workflow model is a series of steps (participant, process, OR split/join) defined in the workflow editor.

Workflow launchers trigger a workflow when content is created, modified, or deleted, based on path and node type.

The inbox holds work items for participants; workflows can be completed, delegated, or stepped back.

Replication is the publish mechanism; it can be triggered manually, via workflow, or scheduled.

The publish queue shows pending replication; agents can be tested and flushed if stuck.

Scheduled activation/deactivation uses the 'Activate Later' or 'Deactivate Later' options.

The Timeline rail shows versions, workflow history, and comments on a page.

Content governance uses permissions, workflow approvals, and the audit log to control who changes what.

The package manager and content packages are used for content transfer and backup.

ContextHub stores client-side context (e.g., geolocation, browser, segment) and is configured per site.

Audiences (segments) are defined in the Audiences console and can be based on context, profile, or custom logic.

Targeting mode in the page editor shows how different audiences see targeted components.

The Targeting component allows authors to define experiences per audience on a page.

Adobe Target integration allows A/B and multivariate tests and personalized offers from AEM.

AEM can use Adobe Experience Platform segments via the Experience Platform integration.

Personalization requires the ContextHub or client context to evaluate segments at request or client time.

Activities in Adobe Target are managed in Target; AEM can export offers and experiences to Target.

Segments can be combined with AND/OR logic; test the audience logic in Targeting mode before publishing.

Adobe Analytics integration is configured via the Cloud Services configuration and the Analytics framework.

The Sites console has a Reports view (e.g., page activity, content insights) when integrations are configured.

Content Insights surfaces analytics data on pages in the page editor.

The Dispatcher caches pages; cache hit ratio and invalidation are key performance levers.

Clientlib minification and combining reduce requests; the AEM clientlibs can be minified via the HTML Library Manager.

The performance budget should be validated with Lighthouse or similar; image renditions should be served responsively.

The replication queue and dispatcher flush logs help diagnose stale content.

AEM as a Cloud Service provides Cloud Manager reports and CDN caching.

The page performance can be monitored via the Request Log Analyzer and the error log on Author/Publish.

Users and groups are managed in the Security console; permissions are granted to groups, and users inherit from groups.

ACLs are set on paths; the permission matrix shows read, modify, create, delete, and replicate.

The 'contributor' and 'author' groups are common; 'administrators' has full access.

AEM as a Cloud Service uses Adobe IMS for authentication; local users are limited.

The package manager and the CRXDE Lite (where available) are admin tools; CRXDE Lite is disabled on Cloud Service.

The audit log records security and content changes; it is used for governance and troubleshooting.

Backups and version purges are admin tasks; version purge removes old versions to control repository size.

The OSGi web console lists bundles, components, and configurations; it is used for troubleshooting.

Business practitioners should validate permissions by impersonating a user in the Security console.