[AEM Forms]{class="badge positive" title="Applies to AEM Forms)."}

Add rules to an Adaptive Form adaptive-forms-rule-editor

The rule editor in Adobe Experience Manager (AEM) enables form authors to add rules to an Adaptive Form, controlling how the form behaves in response to user input. Rules apply business logic to form fields and components without requiring custom code. Using the rule editor, authors define conditions and actions that determine what happens as a user interacts with the form.

Rules in an Adaptive Form commonly perform the following functions:

Because rules encapsulate this logic within the form itself, they create dynamic, adaptive experiences that respond in real time to the user. This reduces manual scripting, improves data accuracy, and streamlines complex form workflows. The article below explains the rule editor interface for foundation components, while the equivalent guidance for other AEM versions and component types is linked in the table.

Overview overview

The rule editor is a visual authoring tool in Adaptive Forms that enables forms business users and developers to write rules on Adaptive Form objects. Rules define actions that trigger on form objects based on preset conditions, user inputs, and user actions on the form. The rule editor streamlines the form-filling experience, ensuring accuracy and speed by automating how the form responds as users interact with it.

The rule editor provides an intuitive, simplified user interface for authoring rules, and offers a visual editor available to all users. Because rules execute automatically in response to conditions and inputs, they reduce manual effort and minimize data-entry errors during form completion.

Key Actions Supported by Rules

Using rules, you can perform the following key actions on Adaptive Form objects:

User Permissions and Access

Access to authoring and using rules is governed by user group membership:

This separation ensures that rule authoring remains controlled while allowing broader groups to benefit from the rules already in place.

Difference between Rule editor in Core Components and Rule Editor in Foundation Components

The primary difference is architectural: the Rule Editor in Core Components is built for the modern, standards-based Adaptive Forms authoring model in Adobe Experience Manager (AEM), while the Rule Editor in Foundation Components supports the older, legacy authoring model. Both let authors add dynamic, conditional logic to form fields without writing code, but they operate on different component frameworks and expose different capabilities.

Rule Editor in Core Components

The Rule Editor in Core Components is designed to work with the newer, extensible Adaptive Forms Core Components. Because Core Components follow a standardized, style-system-friendly architecture, their rules are engineered to be more portable, easier to maintain, and better aligned with responsive, headless, and edge-delivery scenarios. Authors typically use it to build validation, visibility, enablement, and value-calculation rules that behave consistently across modern rendering targets. As widely acknowledged in AEM development practice, Core Components represent the forward-looking, recommended foundation for new form projects, so their Rule Editor is the environment intended to receive ongoing enhancements.

Rule Editor in Foundation Components

The Rule Editor in Foundation Components targets the legacy Foundation Components framework. It provides the traditional capabilities long available in AEM Adaptive Forms — including conditional show/hide behavior, field enablement, required-field toggling, and scripted expressions. Unlike the Core Components editor, the Foundation Components Rule Editor is tied to the older component model, which can make its rules less portable to modern delivery models and more dependent on the legacy rendering stack. As a result, it is most relevant to existing forms already authored with Foundation Components.

Key Differences at a Glance

When to Use Each

Because the two editors are bound to fundamentally different component frameworks, rules authored in one are not directly interchangeable with the other. This is why teams planning long-term Adaptive Forms strategies generally standardize on Core Components and their Rule Editor, reserving the Foundation Components Rule Editor for continuity of legacy implementations.

Understanding a rule understanding-a-rule

A rule is a combination of actions and conditions. In rule editor, actions include activities such as hide, show, enable, disable, or compute the value of an object in a form. Conditions are Boolean expressions that the rule editor evaluates by performing checks and operations on the state, value, or property of a form object. The rule editor performs actions based on the value (True or False) returned when it evaluates a condition. As a result, a condition that returns True triggers its associated action, while a False result does not.

The rule editor provides a set of predefined rule types to help you write rules. These rule types include:

Each rule type lets you define conditions and actions in a rule. The document further explains each rule type in detail.

A rule typically follows one of the following constructs:

Condition-Action In this construct, a rule first defines a condition followed by an action to trigger. The construct is comparable to the if-then statement in programming languages, where a specified condition determines whether the action runs.

In rule editor, the When rule type enforces the condition-action construct.

Action-Condition In this construct, a rule first defines an action to trigger followed by conditions for evaluation. Another variation of this construct is action-condition-alternate action, which also defines an alternate action to trigger if the condition returns False.

The Show, Hide, Enable, Disable, Set Value Of, and Validate rule types in rule editor enforce the action-condition rule construct. By default, the alternate action for Show is Hide, and the alternate action for Enable is Disable, and the opposite way. You cannot change the default alternate action, because these opposite pairings are built into the rule editor to keep behavior predictable and reversible.

For more information about rule types available in the rule editor, see Available rule types in rule editor.

Guidelines for choosing a rule construct guidelines-for-choosing-a-rule-construct

You can achieve most use cases with any rule construct, but the following guidelines help you choose one construct over another. For more information about the available rules in the rule editor, see Available rule types in rule editor.

Available operator types and events in rule editor available-operator-types-and-events-in-rule-editor

The rule editor provides the following logical operators (conditions) and events (triggers), which form authors use to build conditional rules that control form behavior. Operators evaluate the value or state of a form object, while events respond to specific actions in the form lifecycle, such as rendering, value changes, navigation, or data submission.

Comparison and value operators

Events

Available rule types in rule editor available-rule-types-in-rule-editor

The rule editor provides a set of predefined rule types that serve as the building blocks for writing rules. Each predefined rule type is a ready-made template that defines a specific kind of logic or condition, so you do not have to construct rule structures from scratch. Predefined rule types establish consistent, reusable patterns, which reduces errors and speeds up rule creation.

This section examines each available rule type in detail, describing its purpose and typical use. Because the rule types are predefined, they enforce a standardized structure across all rules, making rules easier to read, maintain, and troubleshoot over time.

Why use predefined rule types

Predefined rule types deliver several practical benefits:

For more information about writing rules in rule editor, see Write rules.

When whenruletype

The When rule type follows the condition-action-alternate action rule construct, or, in simpler cases, just the condition-action construct. In this rule type, you first specify a condition for evaluation, followed by an action that triggers when the condition is satisfied (evaluates to True). While using the When rule type, you can combine multiple AND and OR operators to build nested expressions.

Using the When rule type, you can evaluate a condition on a form object and perform actions on one or more objects.

In plain words, a typical When rule is structured as follows:

When on Object A:

(Condition 1 AND Condition 2 OR Condition 3) is TRUE;

Then, do the following:

Action 2 on Object B;
AND
Action 3 on Object C;

When you have a multi-value component, such as radio buttons or a list, Experience Manager automatically retrieves the options and makes them available to the rule creator while the rule for that component is being created. The rule creator does not need to type the option values again.

For example, a list has four options: Red, Blue, Green, and Yellow. While creating the rule, these options (radio buttons) are automatically retrieved and presented to the rule creator so that each value—Red, Blue, Green, and Yellow—can be selected directly within the rule builder without manual entry.

While writing a When rule, you can trigger the Clear Value Of action. The Clear Value Of action clears the value of the specified object. This ensures dependent fields reset appropriately, so having Clear Value Of as an option in the When statement lets you build complex conditions that span multiple fields.

Actions Available in the When Rule Type

The When rule type supports the following actions:

Hide Hides the specified object.

Show Shows the specified object.

Enable Enables the specified object.

Disable Disables the specified object.

Invoke service Invokes a service configured in a form data model (FDM). When you choose the Invoke Service operation, a field appears. On tapping the field, it displays all services configured across all form data models (FDM) on your Experience Manager instance. On choosing a Form Data Model (FDM) service, additional fields appear where you can map form objects with the input and output parameters for the specified service. See the example rule for invoking Form Data Model services.

In addition to a Form Data Model service, you can specify a direct Web Services Description Language (WSDL) URL to invoke a web service. However, because a Form Data Model (FDM) service offers many benefits, it is the recommended approach to invoke a service.

For more information about configuring services in a form data model (FDM), see Experience Manager Forms Data Integration.

Set value of Computes and sets the value of the specified object. You can set the object value to a string, the value of another object, a computed value derived from a mathematical expression or function, the value of a property of an object, or the output value from a configured Form Data Model service. When you choose the web service option, it displays all services configured across all form data models (FDM) on your Experience Manager instance. On choosing a Form Data Model service, additional fields appear where you can map form objects with the input and output parameters for the specified service.

For more information about configuring services in a form data model (FDM), see Experience Manager Forms Data Integration.

The Set Property rule type lets you set the value of a property of the specified object based on a condition action. You can set the property to one of the following:

For example, the Set Property rule enables you to define rules that add check boxes dynamically to the Adaptive Form. You can use a custom function, a form object, or an object property to define such a rule.

To define a rule based on a custom function, select Function Output from the drop-down list, and drag-and-drop a custom function from the Functions tab. When the condition action is met, the number of checkboxes defined in the custom function are added to the Adaptive Form.

To define a rule based on a form object, select Form Object from the drop-down list, and drag-and-drop a form object from the Form Objects tab. When the condition action is met, the number of checkboxes defined in the form object are added to the Adaptive Form.

A Set Property rule based on an object property lets you add the number of checkboxes in an Adaptive Form based on another object property that is included in the Adaptive Form.

The following figure depicts an example of dynamically adding checkboxes based on the number of drop-down lists in the Adaptive Form:

Adaptive Form Action Types

Each action below defines a specific behavior that can be triggered on a form object, enabling dynamic, interactive form experiences. These actions are widely used to control field values, manage focus, handle submissions, and build repeatable content structures.

Clear Value Of Clears the value of the specified object. This resets a single field without affecting the rest of the form, which is useful for removing dependent or conditional entries.

Set Focus Sets focus on the specified object. This directs the user’s cursor to a targeted field, guiding the input flow and improving form usability.

Save Form Saves the form. This preserves the user’s current entries, allowing a partially completed session to be resumed later.

Submit Forms Submits the form. This sends the collected data to the configured submission endpoint or workflow for processing.

Reset Form Resets the form. This clears all entered values and returns every field to its default state.

Validate Form Validates the form. This checks all fields against their configured rules, ensuring data is complete and correct before submission proceeds.

Add Instance Adds an instance of the specified repeatable panel or table row. This enables dynamic content, allowing users to enter multiple sets of related information, such as adding additional line items or repeated field groups on demand.

Remove Instance Removes an instance of the specified repeatable panel or table row. This lets users delete a previously added set of repeatable content, keeping the form free of unneeded entries.

Navigate to Navigates to other Adaptive Forms, other assets such as images or document fragments, or an external URL. This supports multi-step form journeys and linking to supplementary resources, connecting one form experience to related content.

Set Value of set-value-of

The Set Value of rule type dynamically sets the value of a form object based on whether a specified condition evaluates to TRUE or FALSE. This rule establishes a direct, condition-driven link between form objects, allowing one field to populate automatically from another source, a calculation, or backend data.

Supported value sources

The Set Value of rule assigns a target object a value drawn from any of the following sources:

Similarly, the condition that triggers the rule can be evaluated against a component, a string, a property, or values derived from a function or mathematical expression. This flexibility lets authors build both simple value assignments and complex conditional logic within a single rule.

The Set Value Of rule type is not available for certain form objects, such as panels and toolbar buttons, because these objects do not hold a settable value in the same way that input fields do.

Standard rule structure

A standard Set Value Of rule follows this structure:

Set value of Object A to:

(string ABC) OR
(object property X of Object C) OR
(value from a function) OR
(value from a mathematical expression) OR
(output value of a data model service or web service);

When (optional):

(Condition 1 AND Condition 2 AND Condition 3) is TRUE;

Example: Populating a field from a Form Data Model service

The following example takes the value in the dependentid field as input and sets the value of the Relation field to the output of the Relation argument of the getDependent Form Data Model service. As a result, whenever a valid dependentid is entered, the Relation field is populated automatically without manual entry.

Example of Set Value rule using Form Data Model service

Show show

The Show rule type displays or hides a form object based on whether a defined condition evaluates to True or False. When you apply the Show rule, the target object appears whenever its associated condition is satisfied, and it is automatically hidden when the condition is not satisfied. A condition here is a logical expression that resolves to either True (satisfied) or False (not satisfied).

This rule type is used to build dynamic, conditional form behavior, so that form objects appear only when they are relevant to the user. For example, a follow-up field can remain hidden until the user selects an option that makes it applicable, reducing clutter and guiding the user through the form.

How the Show rule works how-show-rule-works

The Show rule type combines two complementary actions in a single rule:

This paired behavior ensures the object’s visibility always stays synchronized with the current state of the condition, because every evaluation resolves to exactly one outcome — shown or hidden.

Rule structure show-rule-structure

A typical Show rule is structured as follows:

Show Object A;

When:

(Condition 1 OR Condition 2 OR Condition 3) is TRUE;

Else:

Hide Object A;

In this structure, Object A is shown when any one of the listed conditions is TRUE, because the conditions are joined with the OR operator. If none of the conditions are satisfied, the Else clause runs the Hide action and Object A is hidden.

Hide hide

The Hide rule type shows or hides a form object based on whether a specified condition is satisfied. Similar to the Show rule type, form authors can use the Hide rule type to control the visibility of a form object dynamically at runtime.

The Hide rule type behaves as follows:

When multiple conditions are combined, they are joined with the AND operator, meaning every condition must be True for the Hide action to execute.

Rule Structure

A typical Hide rule is structured as follows:

Hide Object A;

When:

(Condition 1 AND Condition 2 AND Condition 3) is TRUE;

Else:

Show Object A;

In this structure, Object A is hidden only when the combined condition — Condition 1 AND Condition 2 AND Condition 3 — evaluates to TRUE. Otherwise, the Else branch executes the Show Object A action, making the object visible.

Enable enable

The Enable rule type enables or disables a form object based on whether a specified condition evaluates to TRUE or FALSE. When the condition is satisfied (returns TRUE), the target object is enabled and becomes interactive for the user. When the condition is not satisfied or returns False, the Enable rule type automatically triggers the Disable action, disabling the target object.

This reciprocal behavior means a single Enable rule governs both states of an object: because the Disable action is invoked automatically whenever the condition fails, you do not need a separate rule to handle the disabled state. This ensures the object’s availability stays consistently synchronized with the outcome of the condition throughout the user’s interaction with the form.

The Enable rule type is commonly applied to create dynamic, conditional forms. For example, a submit button can remain disabled until all required conditions are met, or a dependent field can be enabled only when a related selection is made. This helps guide users through valid input paths and reduces incomplete or inconsistent submissions.

A typical Enable rule is structured as follows:

Enable Object A;

When:

(Condition 1 AND Condition 2 AND Condition 3) is TRUE;

Else:

Disable Object A;

In this structure, Object A is enabled only when Condition 1, Condition 2, and Condition 3 are all TRUE simultaneously, since the conditions are combined with the AND operator. If any one of these conditions returns FALSE, the Else clause executes and Object A is disabled, keeping the object’s state directly tied to the combined result of every specified condition.

Disable disable

Similar to the Enable rule type, the Disable rule type disables a form object when a specified condition is satisfied, and enables it otherwise. Disabling a form object makes it non-interactive — the field appears in the form but users cannot edit, select, or enter data into it until the disabling condition no longer holds.

How the Disable Rule Works

The Disable rule type includes built-in complementary behavior: it also triggers the Enable action when the condition is not satisfied or returns False. This means a single Disable rule manages both states of the object. When the defined condition evaluates to True, the object is disabled; when the condition evaluates to False, the object is automatically enabled again.

This dual behavior ensures the form object never remains locked in an outdated state. As a result, you do not need to author a separate Enable rule to reverse the effect — the Disable rule handles both outcomes, keeping the form’s interactive state consistent with the underlying conditions in real time.

The Disable rule type is commonly used to restrict user input dynamically, such as preventing entry into a field until a prerequisite selection is made, or greying out options that are not relevant based on prior responses.

Syntax and Structure

A typical Disable rule is structured as follows:

Disable Object A;

When:

(Condition 1 OR Condition 2 OR Condition 3) is TRUE;

Else:

Enable Object A;

In this structure, Object A is disabled when any one of the specified conditions (Condition 1, Condition 2, or Condition 3) evaluates to True, because the conditions are joined with the OR operator. If none of the conditions are met — the combined expression returns False — the Else clause executes and Object A is enabled.

Validate validate

The Validate rule type validates the value entered in a field by evaluating a logical expression. The rule executes the expression against the field’s value: when the expression resolves to TRUE, the value is accepted, and when it resolves to FALSE, the value is rejected. This ensures that only data meeting your defined criteria is submitted, helping maintain data integrity and reducing errors caused by malformed or unexpected input.

For example, you can write an expression that verifies the text box for specifying a name contains only alphabetic characters — that is, it does not include special characters or numbers. This practical use of validation prevents invalid entries at the point of input, so downstream systems receive clean, correctly formatted data.

A typical Validate rule is structured as follows:

Validate Object A;

Using:

(Expression 1 AND Expression 2 AND Expression 3) is TRUE;

In this structure, multiple conditions are combined with the AND operator, meaning every expression must independently evaluate to TRUE for the overall rule to pass. If any single expression fails, the combined result is FALSE and the value does not comply. This lets you enforce several validation conditions on the same field simultaneously.

Set Options Of setoptionsof

The Set Options Of rule type dynamically adds check boxes to an Adaptive Form. This rule type lets you define the check box options for a form field in one of two ways: from a Form Data Model (FDM) or from a custom function. Because the check boxes are generated by the rule rather than hardcoded, the options remain data-driven and update automatically when the underlying source changes.

Define a rule using a custom function

To define a rule based on a custom function:

Because the check boxes are generated from the function output, the number of check boxes added to the Adaptive Form matches the number of checkboxes defined in the custom function. This ensures the rendered form reflects exactly what the function returns.

To create a custom function, see custom functions in rule editor.

Define a rule using a Form Data Model (FDM)

To define a rule based on a Form Data Model (FDM):

Understanding the rule editor user interface understanding-the-rule-editor-user-interface

The rule editor provides a comprehensive yet straightforward user interface for writing and managing rules in an Adaptive Form. Rules automate form behavior—controlling actions such as showing or hiding fields, enabling or disabling components, setting values, invoking services, and validating user input—without requiring manual coding. This allows form authors to build dynamic, responsive forms directly within the authoring environment. You can launch the rule editor user interface from within an Adaptive Form in authoring mode.

How to launch the rule editor user interface

Follow these steps to open the rule editor:

Components of the rule editor user interface

The following sections describe each component of the rule editor user interface in detail, explaining its role in building and managing form rules.

A. Component-rule display a-component-rule-display

The Component-rule display identifies the Adaptive Form object through which you launched the rule editor, along with the rule type currently selected. This orientation area sits at the top of the rule editor and serves as a persistent reference point, confirming exactly which form component the rule applies to and which category of logic is being defined.

In the above example, the rule editor is launched from an Adaptive Form object titled Salary, and the rule type selected is When. This tells you that any conditions and actions you configure will be attached to the Salary component and evaluated as a When rule, meaning the logic is triggered in response to a defined event or condition on that object.

Because a single Adaptive Form can contain many components—each with its own rules—the Component-rule display helps you confirm you are editing logic for the intended object and rule type. As a result, it reduces the risk of applying a rule to the wrong field and provides immediate context whenever you open or return to the rule editor.

B. Form objects and functions b-form-objects-and-functions-br

The pane on the left in the rule editor user interface includes two tabs — Forms Objects and Functions.

The Form Objects tab shows a hierarchical view of all objects contained in the Adaptive Form, displaying both the title and type of each object. When writing a rule, you can drag-drop form objects directly onto the rule editor. When you drag-and-drop an object or function into a placeholder, the placeholder automatically takes the appropriate value type. This ensures the rule remains valid and reduces manual type configuration.

Form objects are visually flagged by rule status:

The Functions tab includes a set of built-in functions that you can use to compute values in repeatable panels and table rows, and reference in action and condition statements when writing rules. These built-in functions include:

You can also create custom functions to extend this built-in set.

In the left tree of the form objects, you can select any form object to display the rules applied to that object. Beyond navigating through the rules of the various form objects, you can also copy-paste rules between form objects, allowing you to reuse existing rule logic instead of rebuilding it. For more information, see Copy-paste rules.

C. Form objects and functions toggle c-form-objects-and-functions-toggle-br

Tapping the toggle button shows or hides the Form Objects and Functions pane. This single control switches the pane between its visible and hidden states, giving you direct command over whether the panel appears in the workspace.

The Form Objects and Functions pane is the panel that lists the interactive elements available for building or editing a form — such as fields, controls, and the functions that can be applied to them. Because this pane occupies space within the interface, the toggle serves a practical purpose: hiding it frees up screen area for the form canvas itself, while showing it restores immediate access to the objects and functions you need.

Key behaviors of the toggle:

This toggle is especially useful when you want an uncluttered view of the form during layout and review, and then need to bring the objects and functions back into view when you resume editing.

D. Visual rule editor visual-rule-editor

The visual rule editor is the area within the visual editor mode of the rule editor user interface where you write rules. It serves as the primary workspace for building rule logic without manual scripting, letting you construct rules through a graphical, form-driven interface.

The visual rule editor lets you select a rule type and then define its conditions and actions accordingly. Because rule behavior depends on the selected rule type, the editor adapts the available conditions and actions to match that type, ensuring the logic you build is valid for the rule you intend to create.

Key capabilities of the visual rule editor:

You can drag and drop form objects and functions from the Form Objects and Functions pane so that rule logic is assembled visually rather than typed by hand, which reduces manual errors and speeds up rule authoring.

For more information about using the visual rule editor, see Write rules.

E. Done and cancel buttons done-and-cancel-buttons

The Done button saves a rule. You can save an incomplete rule. However, incomplete rules are invalid and do not run, because they lack the conditions or actions required for execution. Saved rules on a form object are listed each time you launch the rule editor from that same form object, allowing you to review, edit, or delete them. You can manage all existing rules from that view. For more information, see Manage rules.

The Cancel button discards all changes made to a rule and closes the rule editor without saving.

Write rules write-rules

The visual rule editor enables users to create and manage rules through a graphical, no-code interface. Rules define the conditions and actions that control how a system responds to specific inputs, events, or data — for example, triggering an action when a condition is met. The visual rule editor presents these components visually, so rules are built by selecting and configuring elements rather than writing code by hand.

What the visual rule editor is

The visual rule editor is a graphical tool for authoring rules without manual coding. It typically represents each rule as a combination of conditions (the criteria that must be satisfied) and actions (what happens when those conditions are met). Because the logic is displayed visually, users can review, adjust, and validate rules more easily than when editing raw code, reducing the likelihood of syntax errors.

Writing rules with the visual editor

Writing rules in the visual editor generally follows a straightforward sequence:

This visual, step-by-step approach makes rule authoring accessible to both technical and non-technical users.

Why use the visual rule editor

The visual rule editor offers several practical benefits:

Using the visual rule editor is the recommended starting point for creating rules, because it provides an intuitive, guided way to translate business logic into working conditions and actions.

Using visual editor using-visual-editor

Learn how to create a rule in the visual editor using the following example loan application form. This walkthrough builds two rules: one that controls field visibility based on user input, and one that performs a mathematical calculation to derive a value.

The Loan Requirements section in the example loan application form requires applicants to specify their marital status, salary, and, if married, their spouse’s salary. Based on the user inputs, the rule computes the loan eligibility amount and displays it in the Loan Eligibility field. Apply the following two rules to implement the scenario:

To write these rules, perform the following steps:

Rule 1: Control Spouse Salary field visibility

Rule 2: Compute loan eligibility

Custom functions in rule editor custom-functions

Apart from the out-of-the-box functions like Sum of that are listed under Functions Output, you can write custom functions that you frequently need. Ensure that the function you write is accompanied by the jsdoc above it.

Accompanying jsdoc is required:

Rule editor supports JavaScript ES5 syntax for scripts and custom functions.
For more information, see jsdoc.app.

Supported jsdoc tags:

Adding a custom function

For example, you want to add a custom function that calculates the area of a square. The side length is the user input to the custom function, which is accepted using a numeric box in your form. The calculated output is displayed in another numeric box in your form. To add a custom function, you first create a client library, and then add it to the CRX repository.

To create a client library and add it to the CRX repository, perform the following steps:

After you have added your client library in the CRX repository, use it in your Adaptive Form. As a result, the custom function becomes available for use as a rule within your form. To add the client library in your Adaptive Form, perform the following steps:

Function declaration supported types function-declaration-supported-types

Function Statement

function area(len) {
    return len*len;
}

This function is included without jsdoc comments.

Function Expression

var area;
//Some codes later
/** */
area = function(len) {
    return len*len;
};

Function Expression and Statement

var b={};
/** */
b.area = function(len) {
    return len*len;
}

Function Declaration as Variable

/** */
var x1,
    area = function(len) {
        return len*len;
    },
    x2 =5, x3 =true;

Limitation: The custom function picks only the first function declaration from the variable list, if declared together. For every function declared, use a function expression to ensure each is recognized.

Function Declaration as Object

var c = {
    b : {
        /** */
        area : function(len) {
            return len*len;
        }
    }
};

Supporting Custom functions in Validation Expressions supporting-custom-functions-in-validation-expressions-br

When forms require complex validation rules, the validation logic resides in custom functions, and the author calls these custom functions directly from a field validation expression. To make this custom function library known and available during server-side validation, the form author configures the name of the Adobe Experience Manager (AEM) client library under the Basic tab of the Adaptive Form Container properties, as shown below.

This configuration establishes a single, reusable location for validation logic that runs both on the client and on the server. Because the same client library is referenced during server-side validation, custom validation functions behave consistently regardless of where the validation executes.

Configuring a custom function library per Adaptive Form:

The form author can configure a custom JavaScript library per Adaptive Form. Within this library, keep only the reusable functions that are called from validation expressions. This ensures the library stays focused, avoids unnecessary code on the server side, and makes validation logic easier to maintain and reuse across fields.

These reusable functions have a dependency on the jQuery and Underscore.js third-party libraries. Because these dependencies must be available for the custom functions to execute correctly, ensure they are loaded alongside the configured client library so that both client-side and server-side validation resolve successfully.

Error handling on Submit Action error-handling-on-submit-action

Configure Custom Error Pages

As part of the Adobe Experience Manager (AEM) security and hardening guidelines, configure custom error pages named 400.jsp, 404.jsp, and 500.jsp. AEM invokes these handlers whenever a form submission returns a 400, 404, or 500 error. AEM also invokes the same handlers when these error codes are triggered on the Publish node, ensuring consistent error responses across both authoring and publishing environments.

Each handler maps directly to a standard HTTP status code:

Administrators can also create additional JSP pages for other HTTP error codes, extending consistent, branded error handling to any response an Adaptive Form may generate.

Preventing Data Loss for Unbounded Fields

Unbounded fields lose their data during prefill when the supplied data does not include the required Adaptive Form data tags. Unbounded fields are Adaptive Form fields that do not have the bindref property, meaning they are not mapped to a schema binding.

This data loss occurs when you prefill a Form Data Model (FDM) or a schema-based Adaptive Form with eXtensible Markup Language (XML) or JavaScript Object Notation (JSON) data that is compliant with a schema but does not contain the following tags:

The supporting schema can be an XML schema, a JSON schema, or a Form Data Model (FDM). Because unbounded fields have no schema binding through the bindref property, AEM relies on the <afUnboundData> container to carry their values. When that container is absent from the prefill data, the values of unbounded fields cannot be resolved and are lost. To preserve unbounded field data during prefill, always include the <afData>, <afBoundData>, and <afUnboundData> tags in the XML or JSON payload.

Manage rules manage-rules

When you select a form object and select , the Manage rules interface lists all existing rules on that object, letting you view each rule’s title alongside a preview of its rule summary. The UI enables you to expand and view the complete rule summary, change the order of rules, edit rules, and delete rules from a single, centralized view.

You can perform the following actions on rules:

Copy-paste rules copy-paste-rules

Copy-paste a rule from one field to other similar fields to save time and ensure consistency across your form. This lets you reuse a configured rule without rebuilding it manually on every form object.

To copy-paste rules, do the following:

Nested expressions nestedexpressions

The Rule editor supports nested expressions, allowing you to combine multiple AND and OR operators within a single rule to build nested rules. Mixing AND and OR operators lets you express complex, multi-condition logic in one rule, so that outcomes trigger only when specific combinations of conditions are satisfied. This capability is essential for scenarios where a single flat condition is insufficient and layered decision logic is required.

For example, a nested rule can display a message to the user about eligibility for a child’s custody, showing the message only when all of the required conditions are met. Because the operators are nested, the Rule editor evaluates each grouped condition together, ensuring that eligibility logic reflects the exact combination of criteria defined in the rule.

Reordering conditions with drag-and-drop

You can also drag-and-drop conditions within a rule to edit its structure without deleting and re-adding conditions. To reposition a condition:

Once the condition is dropped, the rule structure changes to reflect the new arrangement, because the editor re-evaluates the placement of AND and OR operators relative to the moved condition. This lets you refine the logic of a nested rule quickly and preserve the intended eligibility outcomes.

Date expression conditions dateexpression

The Rule editor enables date comparisons to create conditional logic in Adaptive Forms. Date expressions compare one date value against another—most commonly a user-entered date against the current date—and trigger form behavior based on the result.

Example: Displaying an income note based on mortgage date

The following example condition displays a static text object when the mortgage on the house is already taken, which the user indicates by entering a value in the date field.

Because the mortgage date entered by the user falls in the past, the Adaptive Form displays a note about the income calculation. The rule compares the date the user enters with the current date, and when the user-entered date is earlier than the current date, the form displays the text message named Income.

How the date comparison works

The rule evaluates the condition as follows:

When the filled date is earlier than the current date, the form displays the Income text message. The condition remains inactive—and the Income message stays hidden—whenever the entered date matches or is later than the current date, so the note surfaces exclusively for mortgages that are already taken.

Number comparison conditions number-comparison-conditions

The Rule editor lets you create conditions that compare two numbers. A number comparison condition evaluates one numeric value against another and triggers a defined action when the specified relationship — such as less than, greater than, or equal to — is satisfied. Number comparison conditions are commonly used to control form behavior dynamically, showing, hiding, or modifying content based on the values applicants enter.

Example: Requesting additional proof of residence

The following example demonstrates a condition that displays a static text object when the number of months an applicant has been staying at the current address is less than 36 months.

The condition works as follows:

This ensures that the form dynamically adjusts its content based on the value entered, prompting applicants for supplementary documentation only when the residency threshold is not met. As a result, forms remain concise and request additional proof of residence exactly when the business logic requires it.

Example rules example

Invoke Form Data Model service invoke

The Invoke service action calls a service configured in a Form Data Model (FDM), sends form field values as input to that service, and populates the service response back into the form fields. This lets an Adaptive Form retrieve data from an external web service at runtime in response to a user action.

Example scenario

Consider a web service named GetInterestRates that takes three inputs — loan amount, tenure, and the applicant’s credit score — and returns a loan plan that includes the EMI (Equated Monthly Installment) amount and the rate of interest. Because the service both accepts inputs and returns structured output, it is a suitable data source for an Invoke service action on a form.

To implement this scenario, complete the following steps:

As a result of the invocation, the service response — the EMI (Equated Monthly Installment) amount and rate of interest — is mapped to the corresponding output fields on the form. This mapping ensures the returned plan details are populated into the appropriate fields so the user sees the calculated result immediately.

How to configure the Invoke service action

The following rule shows how to configure the Invoke service action to accomplish the example scenario, defining the input arguments passed to the service and the output mapping that returns the results to the form fields.

Triggering multiple actions using the When rule triggering-multiple-actions-using-the-when-rule

A When rule lets a single condition trigger multiple actions on a form, executing all specified behaviors at once when its condition evaluates to True. In a loan application form, the form author wants to capture whether the loan applicant is an existing customer, then drive several field behaviors from that single answer.

Specifically, the form must:

Both behaviors are driven by the same answer, which is why a single When rule is well suited to this scenario: one condition triggers multiple coordinated actions.

Form components

The loan application form has the following components:

Rule logic in the visual editor

When you write a When rule on the radio button to implement this behavior, the rule appears as shown below in the visual rule editor.

Rule in the visual editor

In the example rule, the statement in the When section is the condition. When the condition returns True, the rule executes the actions specified in the Then section. This structure separates the trigger (the applicant’s answer) from the outcome (showing the field and setting focus), ensuring that all defined actions run together whenever the condition is satisfied.

Using a function output in a rule using-a-function-output-in-a-rule

The sum function lets you total the quantities entered across every repeated instance of a table row and display the result in a single non-repeatable cell. In a purchase order form, a table where users fill in their orders can automatically calculate a Total Quantity by applying this function inside a Set Value Of rule.

Table setup

The purchase order form contains a table with the following structure:

A. Row1 B. Quantity C. Total Quantity

Building the Set Value Of rule

The goal is to add the specified quantities in the Product Quantity column across all products and display the sum in the Total Quantity cell. Because productquantity repeats once per ordered product, the sum function is required to collapse those multiple values into a single total. You achieve this by writing a Set Value Of rule on the Total Quantity cell.

To create the rule in the visual editor, follow these steps:

This ensures the total always reflects the current contents of the repeatable row without requiring users to calculate the sum manually.

Validating a field value using expression validating-a-field-value-using-expression

A Validate rule lets you enforce business logic on a field value by evaluating a validation expression whenever the field changes. When the expression condition is met, the form blocks the entry and prevents the user from submitting an invalid value. This makes expression-based validation a reliable way to guard against incorrect data at the point of entry, rather than catching errors later during processing.

The Validation Scenario

In the purchase order form explained in the previous example, the goal is to restrict the user from ordering more than one quantity of any product priced above 10,000. In other words, high-value products (those exceeding a unit price of 10,000) are limited to a maximum order quantity of one, while lower-priced products remain unrestricted. To enforce this rule, define a Validate rule (a validation expression) on the quantity field, as shown below.

How the Validate Rule Works

The Validate rule works by combining two conditions into a single expression:

Because the expression evaluates both the price and the quantity together, the restriction applies only to the specific case that matters — high-value items ordered in bulk — while allowing all other combinations to pass through without interruption.

Building the Rule in the Visual Editor

You define this logic in the visual editor, where the Validate rule is constructed from the field conditions rather than written manually. The visual editor lets you select the relevant fields, set the comparison operators, and combine the price and quantity conditions into the complete validation expression. Once configured, the rule enforces the restriction automatically each time a user attempts to set a quantity for a product priced above 10,000.