Support flexible fiscal date precision in record date fields

What is the challenge?

Aha! date fields currently expect exact calendar dates, even when teams only know timing at a broader planning level such as fiscal week, month, quarter, or year. To represent those plans, users have to manually choose artificial start and end dates that approximate the intended timeframe. This creates inconsistency in how records are entered and makes date ranges function more like reporting workarounds than true planning inputs.

What is the impact?

This reduces reporting accuracy and confidence, especially for organizations that plan and report by fiscal periods rather than exact dates. Teams can end up with misleading rollups, off-by-one errors in month or quarter reporting, and inconsistent interpretations of what a date range actually means. It also adds manual effort, increases training overhead, and makes long-range roadmap data harder to maintain as timing becomes more precise over time. This becomes even more important as AI accelerates planning cycles, because teams will generate and update plans faster than users can manually normalize broad timing into exact dates.

Describe your idea.

Allow date fields on records to support selectable date precision, so a user can specify timing as either an exact date range or as a fiscal week, month, quarter, or year. Instead of forcing users to translate a planning period into exact start and end dates, Aha! would store the intended level of precision directly and use it consistently in reports, views, filters, and integrations. The experience should make the selected precision explicit, preserve fiscal calendar alignment, and still allow teams to refine broader periods into exact dates later when plans mature. This would make Aha! better suited for faster, AI-assisted planning workflows where timing often starts broad and sharpens over time.

Note: Choosing Releases as the category for this idea because of how they'll be used for prioritizing work in our new AI-native operating model, but it also applies to Epics and Features.