AEM Forms Developer Expert common mistakes
AEM Forms Developer Expert · Understand the traps and how to avoid them.
Treating an Adaptive Form as a self-contained artifact and expecting rules or fragments to behave identically across all rendering environments, without checking whether the form is rendered by the AEM Forms JEE stack or the OSGi/Franklin stack.
Candidates memorize feature lists from one stack and assume universal behavior; the two authoring/runtime stacks differ in available features, submission handling, and document service integration.
What to do instead
Before answering architecture questions, explicitly identify which stack (JEE vs OSGi) the scenario implies, and map the feature (e.g., certain submission actions, output options, or workflow integration) to that stack.
Binding form fields to a data model by guessing element names instead of deriving bindings from the actual schema/JSON structure and its hierarchy.
Candidates skim the schema and assume flat field names, then bind to a path that does not exist in the model, causing silent data loss or empty submissions.
What to do instead
Walk the schema tree explicitly; for each field state the full binding path (including arrays and nested objects) and confirm the data model's root element and namespace.
Assuming a Form Data Model service or REST integration will pass through authentication and headers automatically, without configuring the data source authentication and request/response mappings.
Candidates focus on the visual mapping of inputs and outputs and overlook transport-level configuration (authentication type, headers, SSL, timeouts).
What to do instead
For each FDM integration, enumerate the data source authentication, required headers, and input/output mappings separately, and verify the service is invoked with the expected payload shape.
Writing a client-side rule that references a field by its caption or display text rather than its stable name/binding, or assuming rules execute in a guaranteed order across panels.
The visual rule editor encourages picking fields by label, and candidates assume top-to-bottom execution like imperative code.
What to do instead
Reference fields by their defined name/SOM expression, and design rules to be order-independent (or use explicit dependencies/events) rather than relying on authoring order.
Using a custom component or custom function without declaring it in the correct client library category and dependency order, then expecting it to load at runtime.
Candidates register the component but forget the clientlib category, embed relationships, or load-order constraints, so the function is undefined when the rule fires.
What to do instead
State the clientlib category, its dependencies/embeds, and where the component is registered; confirm the library is included on the form's clientlib and loads before form initialization.
Confusing the roles of the various document services (e.g., assembling a PDF from a template vs. converting/rendering output vs. extracting data) and selecting the wrong service for the described task.
Service names overlap conceptually, and candidates answer from memory of a single service rather than matching the task's input/output to the service contract.
What to do instead
For each scenario, name the required input (XDP/template, data XML/JSON, output format) and the expected output artifact, then match to the service whose contract fits; verify against the documented service purpose.
Designing a workflow task assignment without distinguishing between assigning to a user/group and granting the correct permissions on the task, so the assignee can see but not act on the task.
Candidates equate assignment with authorization and skip the permission model for task actions.
What to do instead
For each workflow step, specify assignee, the ACL/permission required to complete the action, and how the task appears in the user's inbox; verify the assignee has both visibility and action rights.
Assuming a form or document is protected because it was placed in a folder with restricted access, without configuring document-level security or the correct service user permissions.
Candidates conflate repository/folder ACLs with document security policies and the permissions of the process/service user executing the action.
What to do instead
Separate the layers: repository ACLs, document security policies, and the service user's permissions. For each, state what is configured and confirm the effective permission of the executing identity.
Estimating deployment or performance outcomes by assuming default thread pools, caches, and document generation settings are sufficient for the described load.
Candidates answer from general intuition about performance rather than identifying the specific tunable (thread pool, cache size, document service concurrency, DB connection pool) relevant to the bottleneck.
What to do instead
Identify the bottleneck resource explicitly (CPU, memory, DB, document rendering, network), name the corresponding configuration knob, and describe how you would measure the effect before and after the change.
Troubleshooting a failing form submission or rendering issue by changing the form design first, instead of checking logs, the submission/rendering pipeline, and the data model/transport layer in order.
Candidates jump to the visible artifact (the form) because it is the most familiar layer, skipping the server-side pipeline where most failures originate.
What to do instead
Use a layered diagnostic order: reproduce and capture the error, check server logs and the specific service/endpoint, verify data model and transport configuration, then inspect the form artifact last.