Form Settings > Conditional autofill

Conditional Autofill, designed to significantly streamline form-filling processes within your workflows! This enhancement allows for intelligent, automated population of form fields based on user actions (like uploading attachments) and predefined conditions. This means faster request initiation, reduced manual data entry, and improved accuracy for end-users.

Configuration

  1. Form Settings Configuration:

    1. A new "Form Settings" option is now available in the form's options drawer.

    2. Within "Form Settings," you can access and configure "Conditional Autofill" rules.

  2. Rule Creation for Autofill Logic:

    1. Define multiple IF conditions and a DO action to trigger autofill.

    2. Specify logic for IF conditions:

      1. Any of the IF conditions match: The action executes if at least one condition is true.

      2. All of the IF conditions match: The action executes only if all conditions are true.

    3. Field-Condition-Value Mapping: Configure rules based on various field types and conditions:

      1. Date (full date): is filled, before, after, is equal to date, not equal to date, in the past, in the future.

      2. Date (time): is filled, before, after, is equal to, not equal to.

      3. Date (date & time): is filled, before, after, is equal to date (compare dates only), not equal to date (compare dates only), in the past, in the future.

      4. Dropdown/Radio/Master/Static dropdown: Is any of, Is neither of, Is filled. (Values will render options with label (value)).

      5. Numeric: Is filled, Is less than, Is greater than.

      6. User component/Text/Attachment/Field Array: Is filled.

  3. Form Settings Edit and Validation:

    1. An explicit "Save" option is provided to save form settings configurations at the workflow draft version level.
    2. If a user attempts to publish an app before saving changes in form settings, an error will be shown under "Un-saved forms" in the "Review" workflow validations.
    3. If form fields used in saved form settings are edited or removed, validation errors ("Incomplete configurations under form settings for ‘form_name’") will be thrown to prompt the user to update the settings.

Improvements

  1. User Experience during Autofill:
    1. A loading state is displayed at the form level while the system executes actions and pre-fills information.
    2. A generic message ("Details are being retrieved...") is shown to the user during this loading state. This message covers both successful pre-fill and scenarios where pre-fill might not complete (e.g., API issues). No specific API error messages will be shown to the end-user to maintain a user-friendly experience.
  2. Default Re-initiation Logic for Autofill (MVP):
    1. The autofill action will re-initiate based on the following default behaviours without requiring specific configuration in this version:
      1. If ANY of the ‘IF’ conditions are met:
        1. Re-initiates if any subsequent IF condition is met.
        2. Re-initiates if the same IF condition is met again.
      2. If ALL of the ‘IF’ conditions are met:
        1. Re-initiates if all conditions are met again.
  3. Item Creation Handling (MVP):
    1. For forms utilising autofill, an item ID will not be created at the initiator input node until the user either saves the item as a draft or successfully submits the request.
    2. Troubleshooting for pre-fill issues can be done by referring to Execution Logs.
  4. Timeout Configurations:
    1. Conditional Autofill Action Timeout: An auto-timeout for the autofill action can be configured under form settings.
      1. Default: 10 seconds
      2. Minimum: 10 seconds
      3. Maximum: 30 seconds
    2. Frontend Timeout: A default frontend timeout of 30 seconds has been introduced for related operations.

DMS Utility App Specifics

The new "Form Settings" option (and thus Conditional Autofill) will be hidden and not available for forms within DMS utility apps.

How to configure a workflow under 'Execute Action'

You can create a workflow which can be initiated by an API. The documentation for the same is available here.

Operator catalog

Each IF condition is a field + operator + value. Which operators appear depends on the field's type:

OperatorMeaningAvailable on
Is filledThe field has a value. For attachments and field arrays, every visible sub-field of every row must be filled (hidden sub-fields are ignored).All field types
Is any ofThe selected value matches one of the listed values.Dropdown, Radio, Master dropdown, Static dropdown
Is neither ofThe selected value matches none of the listed values.Dropdown, Radio, Master dropdown, Static dropdown
Is less thanNumeric comparison against the configured value. Non-numeric input never matches.Numeric
Is greater thanNumeric comparison against the configured value. Non-numeric input never matches.Numeric
BeforeThe entered date (or time) is earlier than the configured one. Time-only fields compare the time of day.Date, Time, Date & time
AfterThe entered date (or time) is later than the configured one.Date, Time, Date & time
Is equal to dateSame calendar day as the configured date (times compare to the second for time fields).Date, Time, Date & time
Not equal to dateDifferent calendar day from the configured date.Date, Time, Date & time
In the pastThe entered date/time is before now (evaluated when the condition fires).Date, Date & time
In the futureThe entered date/time is after now.Date, Date & time

Conditions are grouped with Any (at least one must match) or All (every one must match). Conditions re-evaluate as the user edits the form; when the group matches, the configured action fires.

Webhook request & response

When the conditions match, the form calls the configured webhook (the Execute Action endpoint — typically a workflow exposed via API-triggered initiation) with the current state of the form:

{
  "formData": {
    "leave_type": "sick_leave",
    "from_date": "2026-10-01",
    "employee": "EMP-1042"
  },
  "formDataLabel": {
    "leave_type": "Sick Leave",
    "employee": "Priya Sharma"
  }
}
  • formData — every field's current value, keyed by field identifier.
  • formDataLabel — display labels for selection-type fields (dropdowns, user pickers), so the endpoint can use the label as well as the stored value.

The response tells the form which fields to fill:

{
  "success": true,
  "data": {
    "data": {
      "available_balance": 4,
      "approver": "MGR-2031"
    },
    "dataLabel": {
      "approver": "Rohan Mehta"
    }
  }
}
  • data.data — values to set, keyed by field identifier. A field-array key takes an array of row objects and replaces the array's existing rows.
  • data.dataLabel — display labels for the filled selection-type fields.

Fields are filled silently (no validation-dirtying), and the field whose change triggered the call is never overwritten. While the call is in flight the form is disabled and shows a "retrieving information" loader; the call times out per the configured timeout (10–30 seconds).

Examples

Autofill leave balance. Form has Leave Type (dropdown) and Available Balance (numeric, read-only). Condition: Leave Type Is any of Sick Leave, Casual Leave → Execute Action calls a workflow that looks up the requester's balance for that type and returns { "data": { "data": { "available_balance": 4 } } }. The balance appears as soon as the user picks a leave type.

Fetch asset details. Form has Asset ID (text) and Asset Model, Assigned Since (read-only). Condition: Asset ID Is filled → the webhook receives the ID in formData.asset_id, queries the asset system, and returns the model and assignment date, which autofill the two read-only fields.

What's Next (Future Enhancements)

We are continuously working to improve the Workflow Builder and the new Conditional Autofill capabilities. Future enhancements may include:

  • Advanced Re-initiation Configuration: Granular controls for defining when and how autofill actions re-initiate.
  • Flagging Auto-filled Fields: Visual indicators in the form configuration to denote fields that are targets for autofill, improving clarity for workflow designers (especially for AA integration).
  • Enhanced AA Integration: Options to expose API details for AA to call or define specific behaviours for forms where details are pre-fetched.
  • Configurable Item ID Creation: App-level configuration for when an item ID should be created.
  • Detailed Progress Path: Visual tracking within the workflow for the execution of pre-filling actions and associated utility apps.
  • Dedicated Workflow Utility App for Dynamic Field Population: A specific utility app for managing and linking dynamic field population logic, potentially with navigation from the primary app.
  • Field Mapping Configuration: Introducing a mapper configuration, especially for Workflow utility apps, to define how source data maps to target form fields.

Did this page help you?