AEM Forms Developer Expert cheat sheet

AEM Forms on JEE runs as a separate EAR deployed to a Java EE container (JBoss, WebLogic, WebSphere), while AEM Forms on OSGi (Foundation) runs as packages inside the AEM quickstart JAR.

The OSGi Forms add-on package must match the AEM service pack version exactly; mismatched add-on and service pack levels are a common cause of failed deployments.

Author instance hosts form authoring, the Forms Manager, and the AEM Forms app configuration; publish instances serve rendered adaptive forms and handle submissions.

The Forms add-on requires a Document Services user and a Forms workflow user; the default 'fd-service' user owns Document Services operations and PDF render/sign keys.

Adaptive Forms are authored in the AEM Forms UI (Forms > Forms & Documents); classic AEM Forms (XFA) authoring lives in the legacy Forms Designer and JEE workbench.

The submission and rendering pipeline depends on the 'forms' servlet and the /content/forms/af path; dispatcher rules must allow POST to submit endpoints.

Correspondence Management (letters) requires the Letters and Data Dictionary packages plus the ICM (Interactive Communications) configuration for agent UI.

Output and document services (PDFG) run as the PDF Generator service; it needs native binaries (Office, PDF utilities) installed on the host OS, not inside the JAR.

AEM Forms Workspace is the JEE end-user task UI; AEM Inbox is the OSGi equivalent for assigning and completing workflow tasks.

Adaptive Form structure: form container > panels > field components; panel types are Responsive (grid), Accordion, and Wizard (tabs).

Data binding in the form model uses 'bindRef' to map a field to a data node; an empty bindRef means the field is unbound and not submitted.

Field types come from the component palette: text box, numeric box, date picker, drop-down, radio button, checkbox, file attachment, and panel.

Client libraries attach at the form container level; the theme controls CSS and the clientlib controls JS/CSS behaviors.

Rules editor supports three rule types: Format (apply visual format), Validate (field validation), and Calculate (compute value from others).

Fragment (panel fragment) reuse requires the fragment to be created from a form with matching data model; fragments are stored under /content/af/fragments.

Adaptive Form templates define the initial structure and are stored under /conf; a form created from a template inherits its layout and clientlibs.

The 'Guide Bridge' API is the client-side scripting surface for adaptive forms (guideBridge.getFormData, .validate, .resolveNode).

XFA-based adaptive forms convert using the 'Convert to Adaptive Form' wizard; the resulting form uses an XFA schema and a generated data model.

Form Data Model (FDM) is created from a data source: RESTful web service, SOAP, OData, or a database via JDBC.

FDM services expose read (get), write (insert/update), and delete operations; only services marked 'enabled' are callable from rules.

The FDM's data source must be configured as a 'Data Source Configuration' with a connection pool before the model is created.

Bindings: form fields bind to FDM properties; a panel bound to a collection repeats for each record (repeatable panel).

A form's data model can be a schema (XML/JSON), an FDM, or none (form model = 'None'); switching models after authoring breaks bindRefs.

Pre-fill service populates fields at render time from an FDM get service; submit action posts to an FDM write service or a REST endpoint.

The 'Submit to REST endpoint' action sends the form data as JSON/XML to a configured URL; the endpoint must allow the form's origin.

Data dictionary (in Correspondence Management) defines typed data elements used by letters and interactive communications.

The FDM's 'get' service can be invoked in a rule via 'Invoke Service' to populate dependent drop-downs on change events.

guideBridge API: guideBridge.getFormData() returns the current data object; guideBridge.validate() returns a promise resolving to validity.

guideBridge.resolveNode(path) returns a field's model object exposing .value, .visible, .enabled, and .valid.

The 'setProperty' rule action sets a field property (value, visible, enabled, mandatory) at runtime; 'clearValue' resets a field.

Rule event triggers include initialize, value commit, click, and field change; rules run in the browser, not on the server.

Custom components extend a base adaptive form component via a clientlib with a JS class extending the base; registration uses the component's 'cq:component' node.

The 'dataRef' attribute on a custom component's HTL binds its value into the form data model.

Custom functions in the rule editor are registered via a JS function library (clientlib) and appear in the 'Functions' category.

The 'af' namespace in clientlibs is used for adaptive form customizations; the 'fd' namespace is used for foundation/forms core.

Client-side validation runs before submit; server-side validation is enforced by the submit action and cannot be bypassed by disabling JS.

PDF Generator (PDFG) converts Office, PostScript, and image files to PDF; it depends on native converters installed on the server OS.

Assembler service combines, splits, and manipulates PDFs using a DDX (Document Description XML) file; DDX defines inputs, outputs, and operations.

Output service (in JEE) and Forms Service render XDP templates to PDF, HTML, or other formats; output options are set in the render options.

Forms Service render options include PDF, HTML, and 'PDF with data'; the data XML must conform to the XDP's schema.

The 'Generate PDF' action in an adaptive form submit workflow uses the Output/Forms service to merge form data with an XDP template.

Document of Record (DoR) generation renders a read-only PDF of a submitted adaptive form using a DoR template (XDP or form).

Signatures: PDF digital signature fields require a credential (PFX) configured under Trust Store; the 'fd-service' user must own the signing key.

Correspondence Management letters render via the Correspondence Management service; data dictionaries supply the merge data.

PDFG requires the 'PDF Generator' service to be running and its watch folder configured; failed conversions usually indicate missing native fonts or Office binaries.

AEM workflow models are authored in the Workflow Editor (Models > Create); steps are either participant steps or process steps.

Participant steps assign a task to a user or group; the task appears in AEM Inbox and can be completed with form data.

Process steps invoke an OSGi service or a WorkflowProcess implementation; the 'Process' step passes workflow metadata via the MetaDataMap.

Adaptive form submission can trigger a workflow via the 'Invoke AEM Workflow' submit action, passing the submitted data as payload.

Workflow payload is stored under /var/workflow/instances; the payload path is available as 'workflowData' in process steps.

The 'Forms Workflow' (JEE) uses process orchestration in Workbench with activities; OSGi workflows use the AEM workflow engine.

Task assignment can use dynamic participant chooser (a service implementing ParticipantChooser) to compute assignees at runtime.

Workflow variables (metaDataMap) carry values between steps; 'workflowMetadata' is accessible in participant step forms.

Terminate vs. complete: a terminated workflow does not run remaining steps; 'Complete' advances the token to the next step.

AEM permissions are ACLs on repository paths; forms assets live under /content/forms and /content/dam/formsanddocuments.

The 'forms-users' group is the default group for form authors; 'forms-power-users' can publish and manage forms.

The 'fd-service' system user performs Document Services operations; it must have read access to form assets and templates.

Document Services credentials (PDFG, signing, Reader Extensions) are configured under the Forms > Document Services configuration and stored in the Trust Store.

Reader Extensions adds usage rights to a PDF so Reader can save, sign, or comment; rights are tied to a credential and a policy.

Dispatcher must not cache form submission POST responses; the /content/forms/af servlet paths and submit endpoints are typically excluded from caching.

CSRF protection: AEM forms submissions include a CSRF token; custom submit endpoints must validate or exempt the token appropriately.

Form data at rest is governed by the FDM data source credentials; store database passwords in the data source configuration, not in code.

Publish instance permissions: anonymous users need read on form assets to render public forms; submission requires the appropriate servlet access.

Deploy forms packages via Package Manager (CRX Package Manager) or the 'Deploy' action in Forms Manager; content packages use the 'content' filter.

The Forms add-on is installed once per AEM instance; reinstalling requires stopping the instance and re-running the add-on installer.

Performance: enable dispatcher caching for static form assets, but exclude dynamic form rendering and submit servlets.

The 'Forms' log (com.adobe.aem.forms) and error.log are primary troubleshooting sources; PDFG failures log to the PDFG service logs.

Common render failure: missing clientlib or theme on publish; verify the theme clientlib is included in the form's template.

Repository growth: form submissions stored under /content/forms/fp or the configured submission store; configure a submission data store to offload.

Cluster: forms workflows and Document Services require shared storage for the document store and a shared Trust Store across nodes.

The 'Forms Manager' health check and the OSGi console (system/console) show bundle states; a 'Resolved' forms bundle indicates a missing dependency.

Version compatibility: the Forms add-on version must match the AEM service pack; check the add-on release notes before upgrading.