- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
A date picker stores a day the system can compare and count from; a date typed into a text field stores a sentence, and the difference decides what you can automate later.
Date picker data type: what the field actually stores
A date picker looks like a convenience for the person filling in the form — a small calendar instead of a text box. The part that matters is on the other side of the submission. The value is stored as a date, not as a string of characters that happens to describe one, and that single difference decides whether you can sort by it, compare it with today, count days from it, or fire a reminder off it. field mapping between a form and a crm covers how a form field reaches a CRM field at all; this is about the type of the field it lands in, and what that type allows later.
Three ways a date can be stored, and what each one allows
| Stored as | What the value looks like | What you can do with it |
|---|---|---|
| Text | 3/4/26, March 4th, next Tuesday | Display it. Nothing else reliably. |
| Date | A calendar day, year first | Sort, compare, add or subtract days, trigger on it |
| Date and time | A calendar day plus a clock time in a named zone | Everything a date allows, plus scheduling to the minute |
Custom fields in a CRM come in types — text, number, dropdown, checkbox, file, and a date picker among them — and the type is a promise about what the field will hold. Choosing the date picker tells the system that the value is a calendar day, and from then on every part of the platform that understands days — filters, workflow conditions, date reminders, exports — can use it. Choosing a text field and typing a date into it produces something that looks identical on the contact record and behaves like a sentence: it will sort alphabetically, it cannot be compared with today, and no automation can count towards it.
A date picker returns a day, not a moment
The distinction that catches people is that a plain date has no time zone. The fourth of March is the fourth of March whether the visitor is in Sydney or Seattle, and that is exactly right for a birthday, a renewal date, a policy anniversary or a move-in date. It is the wrong tool for anything that has to happen at a particular hour, because to compare a bare day with now the system has to invent a time — usually midnight, in some zone it chose — and that invented time is where the surprises come from. A reminder set for the day of the date lands the evening before in one zone and the morning after in another, and both sides believe the setting was correct.
The same collision appears wherever a day meets a clock. coupon expiry dates work through it for offers; quiet hours and local time is where a date-driven message meets the rules about when it may be sent at all; and calendar availability rules show what a field that does carry a time zone has to handle. If the event has an hour, use a date and time field and make sure the zone is stored with it. If it does not, use the plain date picker and never let an automation depend on the hour.
What the value looks like once it leaves the form
The picker on screen may show the fourth of March as 04/03/2026 to a British visitor and 03/04/2026 to an American one, but what gets stored is neither display. It is a machine-readable form, year first, that can be read without guessing which number is the month. That is the shape you will meet when reading a webhook payload, in a CSV export, and in what writing records through the API expects from you. It is also the shape to insist on when importing, because any day of the month from the first to the twelfth is ambiguous in a regional format, and a spreadsheet full of them will import with the month and day swapped on roughly a third of the rows with no error at all. The record looks fine. The reminder fires in the wrong month.
Where the type earns its keep
Conditions
Only a date field offers the comparisons that make date logic possible: before a given day, after it, within the next so-many days, more than so-many days ago. A text field offers contains and equals, which is useless for a date. If a workflow needs to branch on whether a contract ends within the quarter, the field it reads has to be a date picker, and the branch has to be written against the field rather than against the text of an email.
Reminders that are not appointments
appointment reminders are built around a calendar booking. A date field is how you get the same mechanism for a day that is not an appointment — a renewal, a warranty expiry, an anniversary, a follow-up the customer asked for in six months. The trigger reads the field, counts back the number of days you set, and starts the sequence. That is only possible because the value is a date the system can do arithmetic on.
Records created from answers
a survey answer that opens an opportunity can carry a date with it: a requested start date, a move date, a deadline. When the answer lives in a date field, the opportunity that is created can hold a real due date rather than a note someone has to re-type, and the pipeline can be sorted by it.
Choosing the picker on the form itself
The date picker is the right control when the day has to be exact and falls within a range a calendar handles comfortably — the next year or so of appointments and start dates, or a recent past event. Where it becomes awkward is a date of birth: paging back decades in a month-view calendar on a phone is a chore, and visitors abandon it. If the picker offers a year selector, that solves it; if not, a set of dropdowns for day, month and year that feed the same date field is kinder to the visitor and still gives you a real date at the end. dropdown options and their stored values cover how the option text and the stored value can differ, which is exactly what makes that pattern work.
There is one honest case for a text field: when the visitor genuinely does not know the date. Sometime in the spring is real information, and forcing it into a calendar invents a precision that does not exist. Store it as text, label the field as an estimate, and do not build automation on it. Everything else about the form’s behaviour — whether the date is mandatory, whether the field appears only after an earlier answer — is governed by required field validation and conditional fields in the usual way.
Changing the type after data exists
The type is fixed when the field is created, and this is where a quick early decision becomes an expensive later one. A text field that has quietly collected a few thousand dates in four different formats cannot simply be switched to a date picker: depending on the platform the existing values are kept as unreadable text, blanked, or the change is refused outright. None of those converts the data.
The safer path is the boring one. Create a new date field, migrate the old values into it in the machine-readable form, spot-check the ambiguous ones by hand, point every workflow and form at the new field, and only then retire the old one. It belongs on the same list as the rest of contact database hygiene, and it is worth keeping an audit trail in a sheet of what was migrated and when, because the first wrong reminder will be reported months later by a customer, not by the system.
A short test before you rely on the field
- Submit the form with a day between the first and the twelfth of a month and confirm the stored value shows the month you intended.
- Filter contacts by that field using a before-or-after condition and confirm the record appears.
- Build a reminder off the field with a one-day offset and check which day it fires on, from a device in a different time zone.
- Export the contact and read the raw value in the file, not in the interface.
- Import that file back into a test record and confirm the date survives the round trip unchanged.
Five minutes here saves a category of support ticket that is otherwise invisible until the first customer asks why their renewal reminder arrived in the wrong month.
Frequently Asked Questions
What data type does a date picker field store?
A calendar date — a day, month and year the system can compare and do arithmetic on. It is not a string of text. That is what lets filters, workflow conditions and date-based reminders use the value; a date typed into a text field cannot be sorted, compared or counted towards.
Does a date picker value include a time zone?
A plain date picker stores a day with no time and no zone, which is correct for birthdays, renewals and anniversaries. Anything that has to happen at a particular hour needs a date and time field with the zone stored alongside it, or the system invents a time and reminders drift by a day.
Why did my imported dates land in the wrong month?
The file used a regional day-month order and the importer read it the other way round. Any day from the first to the twelfth is ambiguous in that format. Import dates in a year-first, machine-readable form and spot-check the ambiguous rows before pointing any automation at the field.
Can I change a text field into a date field later?
The type is fixed when the field is created, and switching does not convert existing values. Create a new date field, migrate the old values into it in a machine-readable form, repoint every form and workflow, and then retire the old field.
When is a text field the right choice for a date?
Only when the visitor genuinely does not know the date. An estimate like sometime in the spring is real information, and forcing it into a calendar invents precision. Store it as text, label it as an estimate, and do not build automation on it.
How do I collect a date of birth without a painful picker?
If the picker offers a year selector, use it. If it only pages month by month, use three dropdowns for day, month and year that feed the same date field, so the visitor is spared decades of paging and you still get a real date at the end.
Which workflow conditions need a real date field?
Before, after, within the next so-many days, and more than so-many days ago. None of those exist for a text field, which only offers contains and equals. Date-based reminders that count back from a stored day depend on the same thing.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.