AEM Business Practitioner cheat sheet

AEM pages are built from components placed in a parsys/layout container; the page component defines the template-level structure and inherited properties.

The page editor has three modes: Edit (author components), Layout (resize/assign responsive grid columns), and Preview (render without authoring chrome).

Inheritance flows from blueprint/live copy or from the page hierarchy; breaking inheritance (cancel inheritance) makes a property local to that page.

Versioning creates an immutable snapshot of a page; a version can be restored, and versions are pruned by configured max-version and max-age rules.

The content tree stores pages as cq:Page nodes with jcr:content holding properties; component instances are nodes with sling:resourceType.

AEM stores authored text in rich text; the RTE plugin set (links, lists, tables, styles) is configured per component dialog, not globally.

MSM live copies synchronize from a blueprint; rollouts push blueprint changes, and each live copy page can suspend or resume inheritance.

Launches create a parallel branch for future content; promote a launch to copy its pages into the source, and production content stays untouched until promotion.

Language copies are created by translation projects or MSM; the language copy root is a cq:Page with a distinct jcr:language value.

Templates come in two kinds: editable templates (stored under /conf, editable in the UI) and static templates (stored under /apps, code-defined).

An editable template pairs a structure (locked layout) with policies that constrain component behavior; the initial content is copied into new pages.

A policy maps a component to allowed properties and is assigned through the template's policy mapping, not on the page itself.

The navigation component reads the page tree; depth and root-level options determine which descendants render as menu items.

Editable template types define allowed templates for a site section; a template must be allowed by its template type to appear in Create Page.

The page properties dialog exposes basic, advanced, thumbnail, and social-media tabs; the vanity URL and redirect live under Advanced.

AEM generates friendly URLs from the page name; the jcr:title drives display text while the node name drives the URL path.

Responsive layout uses the Layout Container with a grid; column spans are stored per breakpoint in the page's layout node.

Client libraries (clientlibs) are defined by categories and included via the page component or template; the categories string controls the load order.

An asset is a dam:Asset node; the original binary sits in the jcr:content/renditions/original child node.

Renditions are generated derivatives (thumbnails, web formats); the processing profile assigned to a folder determines which renditions are created.

Metadata schemas define which metadata fields appear on asset properties; the schema is applied per folder, and inherited schemas cascade down.

Collections are flat groupings of assets usable across folders; smart collections apply a search query to populate membership dynamically.

Tags come from the taxonomy under /content/cq:tags; namespaces prevent collisions, and tags can be nested hierarchically.

A processing profile is assigned to a folder and runs on upload; it can create renditions and apply image or video transcoding.

Asset relationships include references and back-references; deleting an asset referenced by a page leaves a broken reference unless handled.

The Assets HTTP API and Connected Assets let external systems or remote AEM instances deliver assets; connected assets use a shared asset service.

The asset metadata includes dc:title, dc:description, and dc:format; the format value is the MIME type of the original binary.

A workflow model is a graph of steps; participant steps assign work to users or groups, and process steps run automated logic.

Workflow launchers bind a workflow model to a trigger (node created, modified, or removed) with a path and optional conditions.

The inbox shows active workflow tasks; completing a task advances the payload through the model's next transition.

Publish actions include Activate (push to publish), Deactivate (remove), and Delete; the replication agent moves content to the publish tier.

The default replication agents are author-side (push to publish) and publish-side (flush dispatcher); a disabled agent blocks activation.

Tree activation publishes a page and its children; the rollout config and the 'only modified' option control what is sent.

Scheduled activation uses the 'later' option in the publish dialog to set an on/off time; AEM's scheduler triggers the replication.

Workflow payloads can be pages or assets; the workflow console shows instances, and admins can suspend, resume, or terminate them.

Approval steps in a workflow require a participant to accept or reject; rejection routes the payload per the model's transition logic.

ContextHub stores client-side context (audience, geolocation, weather) in stores; segments evaluate against that context to target content.

A segment is a rule set on context data; a targeted component shows different experiences per segment and a default for unmatched visitors.

Activities (A/B tests, targeting) live under /content/campaigns; the activity's experiences map to offers and segments.

Experience Fragments are reusable content groups (web, email, or non-web variants) that can be exported to Adobe Target or third-party systems.

A Content Fragment is structured data defined by a Content Fragment Model; it is headless content, not a rendered layout.

AEM components extend a base component via sling:resourceSuperType; the dialog is defined by the cq:dialog node and its fields.

The component dialog field types include text, pathfield, multifield, and granite/ui/components/coral/foundation/form/select; each maps to a JCR property.

The HTL/Sightly template renders the component; data-sly-use binds a Java model, and data-sly-resource includes another resource.

Experience Fragment variations let one fragment hold multiple layouts; the variation is selected at the point of use or export.

AEM users and groups are JCR principals; membership grants a user the union of all group permissions.

ACLs are stored per node (rep:policy); each entry grants or denies a privilege (read, write, replicate, delete) to a principal.

Permissions evaluate as allow, deny, or none; an explicit deny on a node overrides an allow inherited from a parent.

The permission hierarchy is: read, modify (create/modify/delete), create, delete, replicate, and read/write of ACLs.

The admin user is a member of the administrators group and bypasses ACL checks; the anonymous user governs unauthenticated access.

The useradmin console manages users, groups, and permissions; the classic useradmin UI is at /useradmin and the touch UI is under Tools > Security.

Closed user groups restrict published content; the CUG configuration on a page requires authentication before the page renders.

Impersonation lets an admin act as another user for troubleshooting; it is logged and does not require the target's password.

The replication privilege controls who can activate content; authors need it on their content paths to publish.

AEM Sites reports (Page Activity, Page Views, Referrers) read from Adobe Analytics when the Analytics integration is configured.

The Analytics integration uses the Adobe Experience Cloud (IMS) configuration; the report suite and data source are set in the cloud services config.

The Sites console offers a list view with columns and a card view; column settings persist per user.

Campaigns in AEM organize offers, teasers, and segments; an activity is the runtime object that ties them together.

Adobe Campaign integration links AEM content to email deliveries; the integration uses the Campaign standard or classic connector.

The page activity report shows views, unique visitors, and time on page for pages within the selected site.

Content Insight (page analysis) shows the page's performance against Analytics; it requires the Analytics cloud service on the page.

The bulk editor edits properties across many pages; the CSV report export from the Sites list view produces a downloadable property report.

Target integration lets AEM activities be exported to Adobe Target; the Target cloud service config holds the client code.