Bug Report: Second DateTime Field Not Processing Correctly in Form Submissions

Max Classic
1

Hello Keap Support,

I’m experiencing a critical bug where Keap is inconsistently processing multiple DateTime custom fields submitted through a web form. Despite identical formatting and configuration, only the first DateTime field is properly converted to a datetime object, while the second remains as a string.

Issue Summary

When submitting two DateTime custom fields via a web form:

  • First field: Correctly converted to SQL datetime format
  • Second field: Remains as string, breaking Liquid date formatting in emails

Technical Details

App ID: xc705 Campaign ID: 10441 (VSN 2. Registration) Sequence: Send immediate VSN email confirmation (with date) Web Form URL: Virtual Speed Networking - Promote Her Business

Custom Fields (both configured as Date/Time type):

  • VSNEventNextDateTime
  • VSNEventNextDateTimeFinish (originally named VSNEventNextDateTimeEND)

Form HTML (identical structure):

html

<input id="_VSNEventNextDateTime" name="inf_custom_VSNEventNextDateTime" type="hidden" value="unknown" />
<input id="_VSNEventNextDateTimeFinish" name="inf_custom_VSNEventNextDateTimeFinish" type="hidden" value="unknown" />

Form Submission Values:

_VSNEventNextDateTime: "6/26/25, 2:00 PM"
_VSNEventNextDateTimeFinish: "6/26/25, 3:30 PM"

Form Submission Details (as shown in Keap):

VSNEventNextDateTimeFinish: 6/26/25, 3:30 PM
VSNEventNextDateTime: 6/26/25, 2:00 PM

Both fields show identical formatting in the submission details, confirming the form is submitting them correctly.

How Keap Stores Them:

VSNEventNextDateTime (raw): 2025-06-26 14:00:00.0
VSNEventNextDateTimeFinish (raw): 6/26/25, 3:30 PM

Result: Liquid date formatting works on the first field but fails on the second:

Email Template Liquid Code:

liquid

[[contact.custom_fields.VSNEventNextDateTime | custom: "EEEE, MMMM d, yyyy  h:mma"]] - [[contact.custom_fields.VSNEventNextDateTimeFinish | custom: "h:mma"]] Pacific

Expected Output: “Thursday, June 26, 2025 11:00AM - 12:30PM Pacific”

Actual Output: “Thursday, June 26, 2025 11:00AM - 6/26/25, 3:30 PM Pacific”

The second field shows the raw stored value instead of applying the Liquid format.

Steps Taken to Troubleshoot

  1. Deleted and recreated both custom fields as Date/Time type
  2. Renamed fields (removed “END” suffix in case it triggered special handling)
  3. Swapped order of field assignment in JavaScript
  4. Swapped order of fields in form HTML
  5. Tested different date formats in submission (ISO format, MM/DD/YY format, etc.)
  6. Verified form submission data - both fields receive identical format from JavaScript
  7. Confirmed the issue is field-specific - it’s always the VSNEventNextDateTimeFinish field that fails, regardless of submission order

None of these steps resolved the issue.

Additional Notes

  • Both fields work correctly when set via automation using “Set Field Value”
  • The issue only occurs with form submissions
  • The same Liquid formatting that fails on form-submitted data works fine on automation-set data
  • This suggests the form processor has a bug with multiple DateTime fields

Expected Behavior

Both DateTime fields should be processed identically and stored in the same SQL datetime format, allowing Liquid date filters to work consistently.

Business Impact

This bug prevents us from properly formatting event end times in automated emails, affecting our communication with customers about event schedules.

Environment

  • Form Type: Keap/Infusionsoft web form
  • Field Type: Date/Time custom fields
  • Submission Method: Hidden fields populated via JavaScript

Request

Please investigate why Keap processes only the first DateTime field correctly in form submissions. This appears to be a backend processing bug that affects any form with multiple DateTime fields.

Is there a known workaround or fix for this issue? We need both DateTime fields to function properly for our email automations.

Simple Test to Reproduce

  1. Create two Date/Time custom fields
  2. Add them to a web form as hidden fields
  3. Submit identical datetime values to both fields (e.g., “6/26/25, 2:00 PM”)
  4. Check the raw stored values - the second field will retain the string format instead of being converted to SQL datetime

You can verify this behavior in Campaign 10441 on the web form at Virtual Speed Networking - Promote Her Business.

Thank you for your assistance.

Best regards,
Scott Hanan