I’m running into a few date-related limitations and inconsistencies and would appreciate clarification on whether these are expected behaviors or known gaps.
Workdoc widgets do not support document-level variables. As a result, dynamic filters like “Today” are always evaluated at render time instead of document creation time, making it impossible to create static, date-scoped documents such as daily meetings, reports, or snapshots. In other words, everything is live and dynamic, making processes unsuitable where time-bound accuracy matters.
If incorrect, please help me write a filter to achieve:
[Date Column] is equal to [the creation date / “Today” at time of creation].
Additionally, exploring filters, I noticed that the date conditions “is” and “is only” appear to behave identically in practice, with no observable difference beyond “is only” exposing an “Exact date” condition (screenshot below).
Can someone explain the intended distinction between here or is this just redundant bloat?
At the board level, when a Date column has time enabled, the “Today” action updates only the calendar date and leaves the time unchanged. This behavior is unintuitive, as it’s reasonable to expect “Today” to represent the current timestamp. Is this a deliberate design choice, or a limitation of how date and time are handled internally?
Hello,
I’m running into several date-related limitations and inconsistencies and would appreciate clarification on whether these are expected behaviors or known gaps. Currently, Workdoc widgets do not support document-level variables, which means dynamic filters like “Today” are always evaluated at render time rather than at document creation time. This makes it impossible to create static, date-scoped documents—such as daily meetings, reports, or snapshot
You’re not imagining things. These are real limitations, and they tend to surface as soon as you try to use monday for time-bound or audit-style workflows.
On Workdocs, you’re correct that widgets don’t support document-level variables. Relative filters like Today are always evaluated at render time rather than at document creation time. There is currently no native way to freeze Today to the creation date of the document. Without a stored creation date variable or snapshot behavior, Workdocs remain fully dynamic, which makes them unsuitable for daily reports, meeting notes, or historical records where accuracy over time matters. There is no filter workaround that can reliably achieve a condition like Date column equals Today at time of creation because that value is never persisted.
Regarding the date filter conditions “is” and “is only,” they do appear to behave the same in practice. The only visible difference is that “is only” exposes an Exact date option. If there is an intended technical distinction, such as boundary handling or time inclusion, it is not communicated in the UI or documentation, which makes the distinction confusing and feel redundant.
At the board level, when a Date column has time enabled, setting the date to Today updates only the calendar date and leaves the time unchanged. While this may be an intentional choice to avoid overwriting time data, it is unintuitive for many users who reasonably expect Today to represent the current timestamp. A clearer distinction or an explicit action such as “Set to now” would help prevent misunderstanding.
These are not edge cases. They impact common workflows around reporting, auditing, and operational accuracy. Clearer semantics around date filters, support for frozen dates in Workdocs, and more predictable date and time behavior would significantly improve the experience for time-sensitive use cases.
