AEM Forms Partners

Inventory the portfolio before agreeing any scope

Build a single list of every form your organization asks people to complete, with four numbers against each: annual volume, current completion rate if known, the cost of processing one submission by hand, and the number of back-end systems the data ends up in. That last column is usually the surprise. A short form that has to create a record in a CRM, trigger a document in a case management system and notify a team through a workflow is a substantially bigger piece of work than a long form that emails a PDF to an inbox.

Then classify each form by what it really is. Data capture forms collect information and stop. Transactional forms create an obligation and need identity, audit and often a signature. Assisted forms are completed by staff on behalf of a customer and have different accessibility and speed requirements. Regulated forms have wording that cannot be changed without approval. These categories have different build costs and different governance, and mixing them in one undifferentiated backlog is how estimates go wrong.

Sequencing the first wave

• Start where volume meets manual cost — the highest annual volume with the highest per-submission handling cost pays for the platform fastest.
• Pick a form with a real but not extreme workflow — the first build should exercise routing and integration properly without depending on the hardest system you own.
• Deliberately choose forms that share structure — three forms from the same family produce reusable fragments; three unrelated forms produce three one-offs.
• Avoid starting with the regulated flagship — sign-off cycles on regulated wording will stall a build whose real purpose is proving the approach.
• Leave the forms whose owning department is mid-reorganisation — nobody will be able to confirm the business rules, and unanswered rules are the main cause of forms work stalling.

Adaptive forms, fragments and why the second form should cost less

An adaptive form is AEM's responsive, rule-driven form: it renders on any device, shows and hides sections based on what the person has entered, validates as they go, and can save a partly completed submission for later. A fragment is a reusable piece of a form, such as an address block, a contact panel, a set of employment history fields or a consent section, built once and referenced by many forms. A theme controls appearance across the portfolio so that branding is applied centrally rather than per form.

This reuse layer is what turns a forms program into something with improving economics. The first form carries the cost of building the fragments, the theme, the validation library and the integration patterns. The tenth form should be substantially cheaper, because most of it is assembled from things that already exist. If your tenth form costs the same as your first, the reuse layer either was not built or is not being used, and that is worth checking explicitly at around form five rather than at the end.

The practical requirement is a fragment library with an owner and a rule that new forms are assembled from it before anything new is built. Without that, teams under delivery pressure copy an existing form and edit it, which is faster on the day and produces twelve slightly different address blocks with twelve different postcode validation rules. When the validation turns out to be wrong, you now have twelve fixes instead of one, and no reliable way to know you found them all. Fragment governance sounds like overhead at form three and is obviously worth it by form fifteen.

Rules, validation and saved progress

• Conditional logic belongs in the form, not in guidance text — if a section only applies to some people, hide it rather than asking them to skip it.
• Validate at the point of entry — errors revealed only after submission are a major cause of abandonment on long forms.
• Decide the save-and-resume rule early — how long a partial submission lives, what identifies it on return, and what data protection says about storing it are policy decisions with build consequences.
• Prefill from systems you already trust — pre-populating known data both shortens the form and reduces the correction work downstream.
• Agree the error wording with the team who handles complaints — they know which messages generate calls.

Approval chains are usually the real complexity

The visible form is often the smallest part of the problem. Behind it sits a process: a submission is routed to a team, assessed, possibly returned for more information, escalated above a threshold, approved by two people for certain values, and finally recorded. AEM Forms can model this with workflow, assigning tasks, tracking status and handling the back-and-forth, but only if somebody has written the process down precisely, including the exceptions.

Elicit this by walking a real case end to end with the people who actually do the work, not from a process document. Ask what happens when the applicant does not respond, when the approver is away, when the value sits exactly on a threshold, when a submission has to be withdrawn, and when something must be corrected after approval. Those five questions usually surface rules nobody has documented, and they are the ones that generate change requests if they are discovered during user acceptance testing rather than during design.

Signature and form data models

Acrobat Sign integration is the mechanism for legally meaningful signatures, and it is worth being precise about when you need it. A tick box recording that someone agreed to terms is often sufficient and much simpler. A signature with an audit trail, identity verification and a tamper-evident record is required where the document creates a binding obligation or where a regulator expects evidence. The difference between these two is a meaningful amount of build and cost, so it should be decided per form by someone who can make that call, rather than applied as a default.

The form data model is how a form connects to back-end systems: it describes the data entities and the services that read and write them, so the form can prefill from a record, validate against a live check and post a submission into the system that owns it. The work here is rarely the AEM side. It is whether those back-end services exist, whether they are fast enough to call while someone is waiting, what happens when they are unavailable, and who fixes them when they change. Agree those answers per integration before the form is estimated, because a form whose submission target has no API is a different project.

Accessibility is tested per form, never asserted per project

Forms are where accessibility problems concentrate, because they combine almost every hard case at once: labels, required indicators, error states, focus management, conditional content appearing and disappearing, session time limits, file uploads and multi-step navigation. A platform can be entirely accessible while an individual form built on it is unusable with a screen reader, since the failures come from how this particular form was assembled rather than from the components it used. That is why a project-level or supplier-level claim of conformance tells you almost nothing. The unit of testing has to be the individual form, and the evidence has to be held per form.

A credible test covers keyboard-only completion from first field to confirmation, screen reader announcement of every label, hint and error, visible focus throughout, error messages that identify the field and say how to fix it, sensible announcement when a conditional section appears or disappears, accessible file upload with progress indication, and readable text at two hundred percent zoom. Automated tools catch perhaps a third of the real issues in a complex form, because most of the remainder concern sequence and announcement rather than markup. The rest need a person completing the form with assistive technology end to end, and for high-volume public services that should be someone who uses that technology daily rather than a developer imitating one.

Baselines and drop-off analytics

• Record the current completion rate before you replace anything — without a baseline, any improvement is an assertion.
• Instrument field-level abandonment — knowing that thirty percent leave at the employment history section tells you what to redesign; a single completion number does not.
• Separate device and channel — mobile abandonment on long forms is usually much worse, and the fix is often splitting steps rather than shortening content.
• Track time to complete and error frequency per field — a field that generates repeated validation errors has a wording or format problem.
• Measure downstream too — a form that submits successfully but produces cases needing manual correction has moved the cost rather than removed it.
• Review after four weeks of live data — most of the quick wins in a form's completion rate come from small changes made once real behavior is visible.

Programs rarely stop at one product. Buyers hiring for AEM Forms often pair it with Adobe Analytics partners , Adobe Brand Visibility partners or Adobe Campaign partners , or review the whole Adobe landscape before committing.