User Input

Collects user inputs to start workflow and chatflow applications

Introduction

The User Input node allows you to define what to collect from end users as inputs for your applications.

Applications that start with this node run on demand and can be initiated by direct user interaction or API calls.

You can also publish these applications as standalone web apps or MCP servers, expose them through backend service APIs, or use them as tools in other Dify applications.

Each application canvas can contain only one User Input node.

Input Variable

Preset

Preset input variables are system-defined and available by default.

• userinput.files: Files uploaded by end users when they run the application.

  For workflow applications, this preset variable has been considered legacy and kept only for backward compatibility.

  We recommend using a custom file input field instead to collect user files.

• userinput.query (for chatflows only): The text message automatically captured from the user’s latest chat turn.

Custom

You can configure custom input fields in a User Input node to collect different kinds of user input. Each field becomes a variable that can be referenced by downstream nodes.

Label Name is displayed to your end users.

If a field’s value is something you already know (like a product identifier or tenant ID) and doesn’t have to come from end users, mark it as Hidden & Pre-Filled and supply it yourself. See Hide and Pre-Fill Input Fields for details.

Text Input

Short Text

Accepts up to 256 characters. Use it for names, email addresses, titles, or any brief text input that fits on a single line.

Paragraph

Allows long-form text without length restrictions. It gives users a multi-line text area for detailed responses or descriptions.

Structured Input

Select

Displays a dropdown menu with predefined options. Users can choose only from listed options, ensuring data consistency and preventing invalid inputs.

Number

Restricts input to numerical values only—ideal for quantities, ratings, IDs, or any data requiring mathematical processing.

Checkbox

Provides a simple yes/no option. When a user checks the box, the output is true; otherwise, it’s false. Use it for confirmations or any case that requires a binary choice.

JSON Code

Accepts data in JSON object format, ideal for passing complex, nested data structures into your application.

You can optionally define a JSON schema to validate the input and guide end users on the expected structure and validation requirements. This also allows you to reference individual properties of the object in other nodes.

File Input

Single File

Allows users to upload one file of any supported type, either from their device or via a file URL. The uploaded file is available as a variable containing file metadata (name, size, type, etc.).

File List

Supports multiple file uploads at once. It’s useful for handling batches of documents, images, or other files together.

Use a List Operator node to filter, sort, or extract specific files from the uploaded file list for further processing.

File Processing

Since the User Input node only collects files—it does not read or parse their content—uploaded files must be processed appropriately by subsequent nodes. For example:

• Document files can be routed to a Doc Extractor node for text extraction so that LLMs can understand their content.

• Images can be sent to LLM nodes with vision capabilities or specialized image processing tool nodes.

• Structured data files such as CSV or JSON can be processed with Code nodes to parse and transform the data.

When users upload multiple files with mixed types (e.g., images and documents), you can use a List Operator node to separate them by file type before routing them to different processing branches.

Hide and Pre-Fill Input Fields

Sometimes the workflow needs an input you already know, and asking end users to type it would be friction. Mark such a field as Hidden & Pre-Filled: you supply the value, end users never see the field, and the workflow still receives it.

Imagine your company runs landing pages for many different products, each featuring an AI chatbot. The workflow behind every chatbot is essentially the same; only the product identifier differs.

Rather than maintain a separate workflow per product, you keep just one (with a hidden productName field) and pre-fill a different value on each landing page. End users perceive each page as having its own product-specific chatbot, but behind the scenes, every page passes a different productName into the same workflow.

Hidden fields are not secret. Values travel in the URL query string and are visible in the browser address bar, browser history, and network traffic. For credentials and API keys, use Environment Variables instead.

Single File and File List fields do not support this feature.

1. Enable the Feature

   1. In the Edit Input Field window, uncheck Required if it’s checked. These two options are mutually exclusive.
   2. Check Hidden & Pre-Filled. Optionally set a default value as a fallback when no value is pre-filled at runtime.

   Hidden fields still appear in the Preview panel so you can test the flow without publishing.

2. Pre-Fill the Field

   1. Publish your app.

   2. Choose the method that fits how your end users reach the app.

      Shareable Link

      Use this when end users open the WebApp directly from its link.

      1. In the app’s publishing panel, within the Web App section, click the gear icon next to Launch.
         
      2. Fill in the hidden fields and click Launch. The WebApp opens with your values applied as URL query parameters; copy the URL from the address bar to share.

      To generate many links with different values, use the same pattern to write more yourself, or have a system fill in the values automatically:

      {WEBAPP_URL}?{VARIABLE_NAME}={VALUE}&{VARIABLE_NAME}={VALUE}
      
      # Example: https://udify.app/chat/abc123?productName=Acme&region=us-east
      

      URL-encode any values that contain spaces or special characters (for example, Acme Corp becomes Acme%20Corp).

      Example: A CRM Auto-Fills the Customer ID

      A support team using a CRM can add ?customerId={{customer.id}} to the end of the WebApp URL in their ticket-response templates.

      The CRM substitutes the real customer ID when the rep sends the link, so the chatbot knows which customer it’s talking to without having to ask.

      Embed on Your Site

      Use this when the app is embedded as an iframe or script on your site.

      Same Value for Every Visitor

      Use this when every visitor should receive the same values (a site-wide region, the embedded page’s product ID, etc.).

      1. In the app’s publishing panel, within the Web App section, click Embedded > Pre-Fill Hidden Fields.
         
      2. Fill in the hidden fields. Entered values are baked into the iframe URL and the inputs object of the script snippet.

      Different Value Per Visitor

      Use this when each visitor should receive their own values (the logged-in user’s ID, the page they’re on, etc.).

      In the embed snippet on your site, set each hidden field as a key in the inputs object of window.difyChatbotConfig. Each value is computed at render time from your site’s context, so every visitor gets their own.

      <script>
        window.difyChatbotConfig = {
          token: 'YOUR_TOKEN',
          inputs: {
            productName: getCurrentProduct(),    // from the current page
            tenantId: getCurrentTenant(),        // from your auth system
          },
        };
      </script>