Form Triggers

Start workflows when users submit forms, with built-in form generation and customization.

Form Triggers

Note: Compose is only available for Beta testing. See Welcome to UKG Compose > Beta Disclosure for more information.

The Form Trigger node starts a workflow when a user submits a form. Compose generates the form web page for you, so you don't need to build or host forms externally.

What Form Triggers Are

Form Triggers create web-based forms that start workflows when submitted. Think of them as self-service intake forms that capture structured data from users and automatically trigger workflow processing.

Key characteristics:

  • Generates a complete form web page (no external form builder needed)
  • Accessible via URL (test URL during development, production URL when published)
  • Supports multiple field types (text, email, date, dropdowns, checkboxes, file uploads, etc.)
  • Can require authentication or be publicly accessible
  • Passes submitted form data directly into your workflow

When to Use Form Triggers

Employee Self-Service Requests

Allow employees to submit requests that automatically trigger approval or fulfillment workflows.

Use cases:

  • PTO/time-off requests
  • Equipment or access requests
  • Address or personal information updates
  • Expense reimbursement submissions
  • IT support tickets
  • Training enrollment requests

Pattern: Employee fills out form → Form Trigger starts workflow → Workflow validates data, creates approval request, sends notifications, updates records

Manager or HR Intake Forms

Collect structured input from managers or HR to initiate processes.

Use cases:

  • New hire requisition forms
  • Compensation change requests
  • Termination or offboarding initiation
  • Performance review scheduling
  • Position change requests

Pattern: Manager/HR submits form → Form Trigger starts workflow → Workflow routes for approval, creates downstream tasks, updates systems

Candidate or External User Forms

Gather information from candidates or external users who don't have UKG Pro access.

Use cases:

  • Job application intake
  • Candidate availability scheduling
  • Reference check forms
  • Background check authorization
  • Onboarding document collection

Pattern: External user submits form → Form Trigger starts workflow → Workflow validates, stores data, creates candidate records, sends confirmation

Data Collection and Surveys

Collect feedback, preferences, or other structured data from users.

Use cases:

  • Employee preference surveys (notification preferences, shift preferences)
  • Benefits enrollment elections
  • Emergency contact updates
  • Exit interview feedback
  • Training feedback forms

Pattern: User submits form → Form Trigger starts workflow → Workflow processes responses, updates data tables or external systems, sends confirmation

Approvals and Acknowledgements

Collect approval decisions or acknowledgements via form submission.

Use cases:

  • Policy acknowledgement forms
  • Training completion confirmations
  • Approval decisions from managers (approve/reject with comments)
  • Consent forms for data processing

Pattern: User submits form with decision → Form Trigger starts workflow → Workflow records decision, updates approval status, notifies relevant parties

Form Trigger Components

Form URLs

Form Triggers provide two URLs:

Test URL:

  • Used during workflow development
  • Activated when you select "Execute Step" or "Execute Workflow" in the editor
  • Displays submitted data in the Compose editor for debugging
  • Useful for testing form logic before publishing

Production URL:

  • Used after publishing the workflow
  • Activated automatically when workflow is published
  • Submitted data is not displayed in the editor (check Executions tab to review)
  • Use this URL to share with actual users

Tip: Always test with the Test URL before switching to Production URL and publishing.

Form Structure

Form Title and Description:

  • Title appears as the web page title and main heading
  • Description appears as a subtitle below the heading
  • Use \n or <br> to add line breaks in the description

Form Elements (Field Types):

  • Text - Single-line text input
  • Textarea - Multi-line text input
  • Email - Email address with validation
  • Number - Numeric input
  • Date - Date picker
  • Dropdown - Single-choice or multiple-choice dropdown list
  • Checkboxes - Multiple selection with optional limits
  • Radio Buttons - Single selection from multiple options
  • File - File upload
  • Password - Masked password input
  • Hidden Field - Store values without displaying to user (useful for passing workflow context)
  • Custom HTML - Insert custom content (links, images, instructions)

Field Settings:

  • Field Label - Displayed above the input field
  • Field Name - Used to reference the field in your workflow (e.g., {{ $json.employee_id }})
  • Placeholder - Sample text shown inside the field
  • Default Value - Pre-filled value when form loads
  • Required Field - Force user to complete before submission

Response Behavior

Choose when to respond to the user after form submission:

Form Is Submitted:

  • Responds immediately when user submits
  • Workflow continues processing in the background
  • Use when you want to acknowledge submission quickly without waiting for workflow completion

Workflow Finishes:

  • Waits for the entire workflow to complete before responding
  • If workflow succeeds, shows success message
  • If workflow fails, shows error message to user
  • Use when you want to confirm that processing completed successfully (e.g., "Your request has been approved and your manager has been notified")

Common Workflow Patterns

Pattern 1: Employee PTO Request Form

  1. Form Trigger: PTO Request Form
    • Fields: employee_id, start_date, end_date, pto_type, comments
  2. Data Query node: Get employee manager from UKG Pro
  3. Data Tables node: Check if employee has sufficient PTO balance
  4. IF node: Balance sufficient?
    • Yes: Continue to approval
    • No: Send rejection email, end workflow
  5. Approval node: Send approval request to manager
  6. IF node: Approved?
    • Yes: Update PTO balance, create time-off record, send confirmation
    • No: Send rejection notification

Why this works: Form collects structured request, workflow validates eligibility, routes for approval, and processes the result—all without manual intervention.

Pattern 2: New Hire Requisition Form

  1. Form Trigger: New Hire Requisition
    • Fields: position_title, department, hiring_manager, job_code, start_date, justification
  2. Data Tables node: Insert requisition record (status="pending")
  3. Approval node: Send approval request to department head
  4. Approval node: Send approval request to HR
  5. IF node: Both approved?
    • Yes: Create job posting, notify recruiting team, update requisition status
    • No: Notify hiring manager of rejection, update requisition status

Why this works: Form standardizes intake, workflow enforces multi-level approval, and tracks requisition state throughout the process.

Pattern 3: Candidate Application Intake

  1. Form Trigger: Job Application Form
    • Fields: first_name, last_name, email, phone, resume (file upload), cover_letter
  2. Data Query node: Check if candidate already exists in UKG Pro Recruiting
  3. IF node: Candidate exists?
    • Yes: Update existing candidate record
    • No: Create new candidate record
  4. API Integration node: Attach resume to candidate profile
  5. Notification node: Send confirmation email to candidate
  6. Notification node: Notify recruiter of new application

Why this works: External candidates submit applications without UKG access, workflow creates or updates candidate records automatically, and notifies relevant parties.

Pattern 4: Employee Preference Survey

  1. Form Trigger: Notification Preference Survey
    • Fields: employee_id, email_notifications (checkbox), sms_notifications (checkbox), language_preference (dropdown)
  2. Data Tables node: Upsert employee preferences
    • Update if employee record exists, insert if new
  3. Notification node: Send confirmation email to employee

Why this works: Employees set preferences once, workflow stores them in Data Tables, other workflows query preferences when sending notifications.

Form Customization

Authentication

You can restrict form access using Basic Auth:

  • Requires username and password to access the form
  • Useful for internal forms that should not be publicly accessible
  • Set credentials in the Form Trigger node configuration

For public forms (like candidate applications), use None authentication.

Custom Styling

Override default form styling with custom CSS:

  • Form Trigger node includes a "Custom Form Styling" option
  • Pre-populates with default CSS so you can modify only what you need
  • Allows branding the form to match your organization's look and feel

Pre-filling Form Fields with Query Parameters

You can pre-fill form fields by adding query parameters to the form URL (production mode only):

Example:
If your production URL is: https://your-compose-url.com/form/pto-request

You can pre-fill fields with: https://your-compose-url.com/form/pto-request?employee_id=12345&pto_type=Vacation

This sets employee_id to 12345 and pto_type to Vacation when the form loads.

When to use this:

  • Pre-fill employee information when sending personalized form links
  • Pass context from external systems (e.g., clicking a link in an email pre-fills request details)
  • Reduce data entry for users

Note: Use percent-encoding for special characters (e.g., @ becomes %40, space becomes %20).

Multi-Page Forms

You can create multi-page forms by combining the Form Trigger with additional Form nodes. This allows you to break complex forms into logical steps and even add conditional logic between pages.

Form Components for Multi-Page Forms

Form Trigger (First Page):

  • Starts the workflow and displays the first page of the form
  • Contains the initial form fields
  • Provides the Test URL and Production URL

Form (Next Page):

  • Adds additional pages to the form
  • Can include workflow logic between pages (validation, data queries, conditional branching)
  • Same field types and configuration options as Form Trigger
  • Users see a "Continue" or custom button label to proceed to the next page

Form (Ending Page):

  • Final page of the form that displays a completion message or redirects the user
  • Four completion options:
    • Show Completion Screen - Displays a title and message confirming submission
    • Redirect to URL - Redirects user to a specified URL after submission
    • Show Text - Displays custom HTML or plain text (supports full HTML including <script>, <style>)
    • Return Binary File - Returns a file to the user (useful for generating certificates, receipts, etc.)

Multi-Page Form Pattern

Basic structure:

  1. Form Trigger: Page 1 (collect basic info)
  2. Form (Next Page): Page 2 (collect additional details)
  3. Form (Next Page): Page 3 (optional, collect more info)
  4. Form (Ending Page): Show completion message or redirect

With logic between pages:

  1. Form Trigger: Page 1 (collect employee ID and request type)
  2. Data Query node: Look up employee information
  3. IF node: Branch based on request type
    • If PTO request: Form (Next Page) with PTO-specific fields
    • If equipment request: Form (Next Page) with equipment-specific fields
  4. Validation or processing nodes
  5. Form (Ending Page): Show confirmation message

Multi-Page Form Use Cases

Use Case 1: Conditional Form Branching

Display different form pages based on user selections from earlier pages.

Example: New Hire Intake Form
  1. Form Trigger: Page 1
    • Fields: hire_type (dropdown: "Full-time", "Part-time", "Contractor")
  2. IF node: Check hire_type
    • If "Full-time": Form (Next Page) with benefits enrollment fields
    • If "Part-time" or "Contractor": Form (Next Page) with availability fields
  3. Form (Ending Page): Redirect to employee portal

Why this works: Users only see form fields relevant to their situation, reducing confusion and data entry errors.

Use Case 2: Data Validation Between Pages

Validate user input before allowing them to continue to the next page.

Example: Equipment Request with Approval Check
  1. Form Trigger: Page 1
    • Fields: employee_id, equipment_type, justification
  2. Data Query node: Look up employee's department and manager
  3. Data Tables node: Check if employee has pending equipment requests
  4. IF node: Has pending request?
    • Yes: Form (Ending Page) with message "You already have a pending request"
    • No: Continue to next page
  5. Form (Next Page): Page 2 - Equipment details
  6. Form (Ending Page): Show confirmation and expected approval timeline

Why this works: Prevents duplicate requests and enforces business rules before collecting unnecessary information.

Use Case 3: Progressive Information Collection

Break complex forms into digestible steps.

Example: Candidate Onboarding Form
  1. Form Trigger: Page 1 - Personal Information
    • Fields: first_name, last_name, email, phone, address
  2. Form (Next Page): Page 2 - Employment Information
    • Fields: job_title, department, start_date, manager
  3. Form (Next Page): Page 3 - Emergency Contacts
    • Fields: emergency_contact_name, relationship, phone
  4. Data Query node: Create candidate record in UKG Pro
  5. API Integration node: Send welcome email with onboarding checklist
  6. Form (Ending Page): Redirect to document upload portal

Why this works: Users aren't overwhelmed by a long form. Each page focuses on a related set of information.

Use Case 4: Return a File After Form Submission

Generate and return a document based on form input.

Example: Training Certificate Request
  1. Form Trigger: Page 1
    • Fields: employee_id, training_course, completion_date
  2. Data Query node: Get employee name and details
  3. Code node: Generate certificate PDF using employee data and course information
  4. Form (Ending Page): Return Binary File
    • Return the generated certificate PDF to the user

Why this works: User receives immediate confirmation in the form of a downloadable certificate.

Query Parameters Across All Form Pages

All Form pages (Trigger, Next Page, Ending Page) receive the same query parameters from the initial Form Trigger URL.

Example:
If your Form Trigger URL is: https://your-compose-url.com/form/onboarding?employee_id=12345&hire_date=2024-06-01

All subsequent Form (Next Page) nodes can access employee_id and hire_date as pre-filled values on any page.

Use this to:

  • Pre-fill employee information across all pages
  • Pass workflow context through the entire form
  • Reduce repetitive data entry

Form Branching Considerations

When building forms with branches (using IF or Switch nodes), be aware of how Compose handles multiple branches:

Mutually exclusive branches - Work as expected. Only one branch executes based on conditions.

Multiple branches that may execute - If multiple branches receive data simultaneously (e.g., from a Switch node with multiple matches), Compose executes branches sequentially. Only the last Form (Ending Page) will display, even if earlier branches contain ending pages.

Best practice: Design form workflows with mutually exclusive branches (using IF or Switch nodes with clear conditions) to ensure the correct ending page displays.

Security and HTML Content

Form Triggers automatically sanitize HTML content to prevent security vulnerabilities.

Allowed HTML tags:

  • Basic formatting: <b>, <i>, <u>, <strong>, <em>, <code>
  • Structure: <div>, <span>, <p>, <br>, <h1> through <h6>
  • Lists: <ul>, <ol>, <li>
  • Links and media: <a>, <img>, <video>, <iframe>
  • Tables: <table>, <tr>, <td>, <th>, <thead>, <tbody>

Restricted tags (automatically removed):

  • <script>, <style>, <input>, <form>, <button> and other potentially dangerous elements

Why this matters: Custom HTML fields and form descriptions support formatting, but Compose blocks content that could create security risks or interfere with form functionality.

Considerations and Best Practices

Form Data Validation

Always validate form input in your workflow:

  • Check that required business rules are met (e.g., PTO balance, valid dates)
  • Verify that employee IDs or other references exist in UKG Pro
  • Sanitize free-text fields before storing or displaying them
  • Use IF nodes and validation logic to enforce business rules

Don't rely solely on form field validation (like "required field") — users can bypass client-side validation. Always validate in the workflow.

User Experience

Provide clear feedback:

  • Use the "Respond When" setting to control when users see confirmation
  • Customize response text to explain what happens next
  • Send follow-up email confirmations for important requests

Keep forms simple:

  • Only ask for information you actually need
  • Use dropdowns and checkboxes instead of free text when possible (reduces errors)
  • Break complex forms into multiple pages if needed

Testing Forms

Always test before publishing:

  1. Use the Test URL to submit test data
  2. Verify that workflow processes data correctly
  3. Check that validations and approval logic work as expected
  4. Test both success and failure paths
  5. Only switch to Production URL and publish when confident

Monitoring Form Submissions

Track form submissions:

  • Review Executions tab to see all form submissions and workflow results
  • Use Data Tables to log form submissions for audit purposes
  • Set up notifications for failed form workflows (indicates data issues or processing errors)

Related Pages

Other trigger types:

Workflow building:

Related nodes:

Security: