Skip to main content

Input Components

Input components are the building blocks for your forms. They handle various types of user input, from simple text to complex data structures.

Available Input Components

  • Text Field: Single-line text input
  • Hidden: Invisible field for storing data
  • Text Area: Multi-line text input
  • Number: Numeric input field
  • Date/Time: Calendar and time selection
  • Checkbox: Single yes/no boolean toggle
  • Select: Dropdown list of options
  • Currency: Monetary value input with currency symbol
  • Location: Captures geographic location coordinates
  • Radio: Single-option selection from multiple choices
  • File: Allows users to upload files
  • Email: Input field specifically for email addresses
  • Phone Number: Input field for phone numbers with formatting
  • Data Grid: Tabular data entry component
  • Password: Masked input for sensitive information
  • Survey: Multi-question rating or feedback collection
  • Signature: Captures electronic signatures
  • QR Scanner: Scan QR codes and barcodes using device camera or image upload

Using Input Components

To add an input component to your form:

  1. Locate the component in the Input Components section of the sidebar
  2. Drag the component onto the form canvas
  3. Click on the component to select it
  4. Configure its properties in the Component Settings Panel

Input Component Details

Text Field

Purpose: Collects single-line text input from users.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example text shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled text when the form loads
  • Prefix/Suffix: Text or icons displayed before/after the field
  • Input Mask: Format the input as users type (e.g., phone numbers, dates)
  • Multiple Values: Allow users to enter multiple values
  • Transform to Hyperlink: Automatically convert URL values to clickable hyperlinks in form submissions
  • Validation: Set required, minimum/maximum length, pattern matching

Purpose: Automatically converts URL text values into clickable hyperlinks in form submissions.

How to Enable:

  1. Select the Text Field component in your form
  2. Navigate to the Display tab in Component Settings
  3. Check the "Transform to Hyperlink" checkbox
  4. Save your form configuration

How It Works:

  • When enabled, text field values containing URLs will be displayed with a clickable button addon in form submissions
  • The original text value remains visible as a disabled input field
  • A button with an external link icon appears next to the field
  • Clicking the button opens the URL in a new browser tab

Supported URL Formats:

  • https://example.com
  • http://example.com
  • example.com (automatically adds http://)
  • subdomain.example.com
  • example.com/path/to/page
  • Various TLDs (.com, .org, .co.uk, etc.)

Best Practices:

  • Use clear, concise labels
  • Provide placeholder text as examples
  • Use input masks for formatted data (e.g., phone numbers)
  • Set appropriate validation rules

Text Area

Purpose: Collects multi-line text input from users.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example text shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled text when the form loads
  • Rows: Number of visible text rows
  • Validation: Set required, minimum/maximum length

Best Practices:

  • Use for comments, descriptions, or other longer text inputs
  • Set appropriate row count based on expected input length
  • Consider character limits for database storage

Number

Purpose: Collects numeric input from users.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example number shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled number when the form loads
  • Prefix/Suffix: Text or icons displayed before/after the field (e.g., $, %)
  • Decimal Places: Number of decimal places to display
  • Thousands Separator: Character used to separate thousands (e.g., comma)
  • Validation: Set required, minimum/maximum values, integer only

Best Practices:

  • Use for quantities, amounts, measurements, etc.
  • Configure appropriate decimal places for the data type
  • Add prefix/suffix for units or currency symbols
  • Set reasonable min/max values to prevent errors

Password

Purpose: Collects sensitive information with masked input.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example text shown before user input
  • Description: Additional information about the field
  • Validation: Set required, minimum/maximum length, pattern matching
warning

Password fields are not encrypted in storage — they are stored as plain text. Do not use this component for genuinely sensitive credentials. Use it sparingly, and only when the platform's data access controls are sufficient for your security requirements.

Best Practices:

  • Use only when necessary
  • Provide clear requirements for the expected value
  • Consider adding a confirmation field

Email

Purpose: Collects email addresses with format validation.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example email shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled email when the form loads
  • Multiple: Allow multiple email addresses
  • Validation: Set required, email format validation

Best Practices:

  • Use for collecting contact email addresses
  • Enable multiple option when collecting multiple contacts
  • Always use email format validation
  • Consider adding a confirmation email field for important forms

Phone Number

Purpose: Collects phone numbers with optional formatting.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example phone number shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled number when the form loads
  • Input Mask: Format the phone number as users type
  • Validation: Set required, phone format validation

Best Practices:

  • Use input masks to ensure consistent formatting
  • Consider international users when configuring format
  • Provide example format in the placeholder or description
  • Use phone number validation pattern

URL

Purpose: Collects web addresses with format validation.

Configuration Options:

  • Label: The field name displayed to users
  • Placeholder: Example URL shown before user input
  • Description: Additional information about the field
  • Default Value: Pre-filled URL when the form loads
  • Validation: Set required, URL format validation

Best Practices:

  • Use for collecting website addresses
  • Include the protocol (http:// or https://) in examples
  • Consider adding URL validation to ensure proper formatting

Location

Purpose: Captures geographic location coordinates.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Validation: Set required validation

How It Works:

  • When the form loads, the component requests the user's current location
  • The coordinates (latitude, longitude) are captured and displayed in the field
  • A Google Maps embed is shown below the field displaying the location
  • The location data is stored in the format "latitude, longitude"
note

OSPROV hides several advanced options on the Location component — multiple values, unique, calculated value, and custom validation are not available. Treat it as a capture-only component: add it, and it does its job.

Best Practices:

  • Use only one Location component per form
  • Provide clear instructions about why location data is being collected
  • Consider privacy implications and only use when location is necessary
  • If the submitter denies geolocation permission, the field stays empty — inform submitters that permission is required

Date/Time

Purpose: Collects date and/or time values with a picker interface.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Default Value: Pre-filled date/time when the form loads
  • Format: How the date/time is displayed (e.g., MM/DD/YYYY)
  • Enable Time: Include time selection
  • Enable Date: Include date selection
  • Minimum Date: Earliest selectable date
  • Maximum Date: Latest selectable date
  • Validation: Set required, date range validation
note

Date/Time values are stored in ISO format internally. If a downstream document or workflow template expects a different format (e.g. DD/MM/YYYY), apply the formatting in a workflow transform — not in the component itself.

Best Practices:

  • Use consistent date formats throughout your forms
  • Set min/max dates to prevent invalid selections
  • Consider time zones for time inputs
  • Handle format conversion in a workflow transform, not the component

Select

Purpose: Provides a dropdown list of options for selection.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Data Source: Where options come from — Values, Raw JSON, Custom, URL, or Resource (Resource is not applicable in OSPROV)
  • Multiple: Allow multiple selections
  • Default Value: Pre-selected option(s) when the form loads
  • Search Enabled: Allow searching within options
  • Validation: Set required validation
note

Each option has a Label (what the user sees) and a Value (what gets stored and exported). These are not always the same. If a submission shows unexpected data, check that the option Values are set correctly — not just the Labels.

For loading options from MasterData, JSON, or JavaScript, see Data Sources and Dynamic Options.

Best Practices:

  • Use for lists with more than 5 options
  • Group related options together
  • Provide clear, concise option labels
  • Enable search for long lists

Radio

Purpose: Provides a list of mutually exclusive options.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Data Source: Where options come from (values, URL, resource)
  • Default Value: Pre-selected option when the form loads
  • Validation: Set required validation

Best Practices:

  • Use for 2-5 options that are mutually exclusive
  • Arrange vertically for better readability
  • Use clear, concise option labels

Checkbox

Purpose: A single boolean toggle — checked (true) or unchecked (false).

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Default Value: Checked or unchecked by default
  • Validation: Set required validation

Best Practices:

  • Use for yes/no or agree/disagree options
  • Write clear, action-oriented labels (e.g. "I confirm the amount" not just "Confirm")
  • In conditions, compare against true (checked) or false (unchecked) — not the string "true"

File

Purpose: Allows users to upload files to the form.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Multiple Files: Allow multiple file uploads — enabled by default
  • Storage: Where files are stored (URL)
  • File Types: Allowed file extensions
  • Validation: Set required validation
note

The maximum file upload size is a platform-wide admin setting and cannot be changed from the form builder. If users are hitting upload limits, contact your system administrator.

Image Thumbnails

Uploaded images (JPG, PNG, GIF) are automatically displayed as thumbnails in the submission view. No configuration is needed.

Best Practices:

  • Communicate any file type restrictions in the field description
  • If the form is likely to receive large files, confirm the platform upload limit with your administrator before publishing
  • Consider security implications of file uploads

Signature

Purpose: Captures electronic signatures.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Height: Height of signature area (default: 200px)
  • Background Color: Color of signature area
  • Pen Color: Color of signature line
  • Validation: Set required validation

The stored value is a base64-encoded PNG image. It is displayed as an image in the submission view.

note

In OSPROV, the Data and Logic tabs are hidden for Signature. The Validation tab remains available to mark it as required, and the Conditional tab is available if you need to show or hide it based on another field.

Best Practices:

  • Set the Height field to at least 200px for comfortable signing on mobile devices — the default can be quite small
  • Use for collecting legally binding signatures
  • Consider legal requirements for electronic signatures in your jurisdiction

Currency

Purpose: Collects monetary values with currency formatting.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Default Value: Pre-filled amount when the form loads
  • Currency Symbol: Symbol to display (e.g., $, €, £)
  • Decimal Places: Number of decimal places to display
  • Thousands Separator: Character used to separate thousands
  • Validation: Set required, minimum/maximum values

Best Practices:

  • Use for financial forms and payment information
  • Configure appropriate currency symbol for your region
  • Set reasonable min/max values to prevent errors

Data Grid

Purpose: Allows users to enter tabular data with multiple rows and columns.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Columns: Define the columns and their types
  • Default Value: Pre-filled rows when the form loads
  • Add Another Text: Text for the button to add new rows
  • Validation: Set required, minimum/maximum rows

Best Practices:

  • Use for collecting structured, repeating data
  • Keep column count reasonable (typically under 6)
  • Provide clear column headers
  • Consider performance implications for large grids

Survey

Purpose: Collects ratings or feedback on multiple questions.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Questions: List of questions to rate
  • Values: Rating scale options
  • Default Value: Pre-selected ratings when the form loads
  • Validation: Set required validation
  • Scale Type: Rating scale (1-5, 1-10, stars, etc.)
  • Scale Labels: Text descriptions for scale points
  • Custom CSS Class: Apply custom styling

The stored value is an object — each question key maps to the selected answer value. Make sure your question keys are meaningful, not auto-generated defaults like question1, question2.

note

Unique validation is not available on the Survey component. Conditional logic and the Calculation tab are available if needed.

Best Practices:

  • Use for satisfaction surveys, feedback forms, and multi-question ratings
  • Keep questions clear and concise
  • Use consistent answer scales throughout the grid
  • Provide descriptive labels for scale points
  • Avoid leading questions

Hidden

Purpose: Stores data that is not visible to users.

Configuration Options:

  • Label: The field name (not displayed to users)
  • Default Value: The value to store
  • Custom CSS Class: Apply custom styling

Best Practices:

  • Use for storing system values, IDs, or other data not meant for user interaction
  • Avoid storing sensitive information in hidden fields
  • Use for passing data between form pages or to workflows

Address

Purpose: Provides a structured way to collect address information.

Configuration Options:

  • Label: The field name displayed to users
  • Description: Additional information about the field
  • Required: Whether the field must be completed
  • Address Format: Regional address format to use
  • Enable Address Validation: Integration with validation services
  • Custom CSS Class: Apply custom styling

Best Practices:

  • Use appropriate address format for your target region
  • Consider enabling address validation for data quality
  • Provide clear instructions for international addresses
  • Consider privacy implications when collecting addresses
  • Includes fields for:
    • Street address
    • City
    • State/Province
    • Postal/ZIP code
    • Country

QR Scanner

Purpose: Captures QR code or barcode data directly within a form using the device camera or an uploaded image, eliminating manual data entry.

Configuration Options:

  • Label: The field name displayed to users
  • Field Key: Unique identifier used in submission data (default: qrCode). Change this when using multiple QR Scanner fields in one form
  • Placeholder: Hint text shown inside the input field when empty
  • Description: Additional information about the field
  • Auto-close on success: Automatically stops the camera feed once a code is detected
  • Allow file upload: Enables a From Image button so users can scan from an image file instead of the camera
  • Prefer back camera: Uses the rear-facing camera on mobile devices (recommended for scanning physical codes)
  • Validation: Set required, minimum/maximum length, pattern matching

How It Works:

  • Click Scan (Camera), grant camera permission, and point the camera at a QR code or barcode — the decoded value is populated automatically
  • Click From Image to upload a JPEG, PNG, or WebP image containing a code instead of using the camera
  • Camera scanning requires a secure context (HTTPS). On plain HTTP the camera button is disabled; image upload remains available
  • Camera access may be restricted inside the Form Builder preview iframe — test on the published form page

Best Practices:

  • Use a unique Field Key when adding more than one QR Scanner to a single form
  • Ensure the form is served over HTTPS in production so camera scanning is available
  • Use Regular Expression validation to enforce a specific code format when needed