Dynamic form API generation for onboarding reduces manual config by 80%

BPM Mendix
, , , , , , , ,
1

We implemented a dynamic form schema API for our employee onboarding process that eliminated 80% of manual form configuration. Previously, each department’s onboarding workflow required custom form development - IT needed asset requests, Finance needed bank details, HR needed emergency contacts. We built a metadata-driven forms API that generates form schemas dynamically based on role and department. The API integrates with our external HR system (Workday) to pull employee metadata and returns JSON form schemas that our Mendix forms management module renders automatically. When HR adds a new department or changes onboarding requirements, they update metadata in Workday - no Mendix development needed. Here’s the core API pattern we used:


GET /api/forms/onboarding?employeeId=E123&department=Engineering
Response: {
  "formSchema": {...fields, validations, dependencies...},
  "prefillData": {...from HR system...}
}

Time-to-launch for new onboarding workflows dropped from 2 weeks to 2 days. Sharing this approach for others facing similar form configuration overhead.

2

This is brilliant! How do you handle form validation rules in the dynamic schema? Are validations also metadata-driven, or do you have a predefined set of validation types that can be applied?

3

Conditional logic is built into the schema. Each field can have a ‘visibilityCondition’ that references other field values. The forms module evaluates these conditions client-side to show/hide fields dynamically. For your dependents example, the schema would include: "visibilityCondition": "hasDependents == true". We support basic operators (==, !=, >, <, contains) and can chain multiple conditions with AND/OR. This covers 95% of our conditional logic needs.

4

Validations are metadata-driven with a validation rule engine. The schema includes validation specifications like required fields, regex patterns, min/max values, and cross-field dependencies. We support about 15 standard validation types. The Mendix forms module interprets these and applies client-side and server-side validation automatically. For complex business rules, we allow custom validation microflows to be referenced by name in the schema.

5

I want to expand on the implementation details for others considering this approach, covering the dynamic form schema API design, metadata-driven forms architecture, and external HR integration patterns.

Dynamic Form Schema API Design:

Our API follows a three-layer architecture:

  1. Schema Generation Layer: Queries metadata repository (Workday in our case) to build form schema based on employee context (role, department, location, employment type). The schema is JSON-based following JSON Schema specification with custom extensions for Mendix-specific rendering hints.

  2. Prefill Data Layer: Fetches employee data from HR system and cached Mendix data to populate form fields. Uses intelligent caching - static data (department structure) cached for 24 hours, dynamic data (employee details) cached for 1 hour.

  3. Validation Layer: Applies validation rules from metadata and executes custom validation microflows referenced in schema. Validations run both client-side (for UX) and server-side (for security).

API endpoint pattern:


GET /api/forms/onboarding?employeeId={id}&department={dept}&role={role}
GET /api/forms/onboarding/validate (POST with form data)
POST /api/forms/onboarding/submit

Metadata-Driven Forms Architecture:

The schema structure we use:


{
  "formId": "onboarding-engineering-2024",
  "title": "Engineering Onboarding",
  "sections": [
    {
      "sectionId": "personal-info",
      "title": "Personal Information",
      "fields": [
        {
          "fieldId": "email",
          "type": "email",
          "label": "Work Email",
          "required": true,
          "validation": {"pattern": "^[a-z]+@company\.com$"},
          "prefillSource": "hr.workEmail"
        }
      ]
    }
  ],
  "fieldDependencies": [...],
  "submitEndpoint": "/api/forms/onboarding/submit"
}

Key design decisions:

  • Field types match HTML5 input types plus custom types (signature, file-upload, multi-select)
  • Validation rules use JSON Schema validation vocabulary
  • Field dependencies support conditional visibility and value dependencies
  • Prefill sources map to HR system fields or Mendix entities

External HR Integration (Workday):

Three integration patterns:

  1. Batch Sync (nightly):

    • Full sync of organizational structure, employee core data, onboarding templates
    • Stores in Mendix for fast access
    • Handles deltas to avoid full reload

  2. Real-time Lookup (on-demand):

    • Validates employee IDs, checks employment status
    • 2-second timeout with fallback to cached data
    • Used sparingly to avoid latency

  3. Webhook Notifications (event-driven):

    • Workday pushes changes when employee data or onboarding templates change
    • Invalidates relevant caches
    • Triggers re-generation of affected form schemas

Integration is built using Mendix REST Consume module with OAuth2 authentication. We maintain a connection pool and implement circuit breaker pattern to handle Workday outages gracefully.

Implementation Benefits:

  • 80% reduction in manual form configuration (measured over 6 months)
  • Time-to-launch: 2 weeks → 2 days for new onboarding workflows
  • HR self-service: Non-technical HR staff can modify onboarding requirements
  • Consistency: All forms follow same UX patterns automatically
  • Maintenance: Single form rendering engine vs. dozens of custom forms

Challenges and Solutions:

  1. Complex Validation Logic: Some business rules were too complex for declarative validation. Solution: Allow custom validation microflows referenced by name in schema.

  2. Performance with Large Forms: Forms with 50+ fields had slow initial load. Solution: Implement lazy loading for sections - only load visible sections initially.

  3. Version Management: Changes to metadata could break in-progress forms. Solution: Schema versioning - each form instance locks to schema version at creation time.

  4. Testing: Difficult to test all form variations. Solution: Automated schema generation tests and visual regression testing with Selenium.

Recommendations for Implementation:

Start small - implement for one onboarding workflow first. Prove the concept before expanding. Focus on the 80/20 rule - cover common cases with metadata, allow custom development for edge cases. Build comprehensive schema documentation and validation tools. Invest in monitoring - track schema generation time, form load time, and error rates. Most importantly, involve HR early - they’re your primary users of the metadata configuration.

This approach works beyond onboarding - we’ve extended it to performance reviews, leave requests, and equipment procurement. The pattern is universally applicable wherever you have repetitive form-based workflows with similar structure but different field requirements.

6

We’re implementing something similar. Did you encounter any challenges with conditional field logic? For example, if an employee selects ‘Yes’ for ‘Has dependents’, we need to show additional fields for dependent information. How does your dynamic schema handle these dependencies?

7

We use a hybrid approach. Employee core data (name, department, manager) is synced nightly to Mendix. When the form API is called, we fetch this cached data for prefilling. For real-time validation like checking if an employee ID exists in Workday, we make synchronous calls but with 2-second timeout and fallback to cached data. This keeps form loading fast while ensuring data accuracy. We also cache form schemas for 1 hour since onboarding requirements don’t change frequently.

8

How does the external HR integration work? Do you pull employee metadata in real-time when the form loads, or is there a sync process? I’m concerned about latency if the HR system is slow to respond.