Custom Quarters: Clarification needed

[Rick_MacDuffie]

Happy Holidays All! I'm investigating the use of custom quarters to define fiscal years. My business owners have created several portfolios to organize their work by fiscal year (eg. 2018 Portfolio X, 2019 Portfolio X & 2020 Portfolio X). This presents all sorts of issues as each portfolio duplicates a significant number of programs and you can't really tell which program your filtering on unless you also name the program with the annual prefix. I digress... I've setup a handful of custom quarters thinking that I could filter on those and have a well defined, reliable period of time. 1/1/2017 to 12/31/2017 1/1/2018 to 12/31/2018 1/1/2019 to 12/31/2019 1/1/2020 to 12/31/2020 Easy peasy. In practice though, when I select these as filter criteria it automatically ADDS an indication of time. 1/1/2019 to 12/31/2019 becomes 1/1/2019 12:00 AM to 12/31/2019 12:00 AM. I suspect that would exclude a project that has a planned completion date of, say, 12/31/2019 5:00 PM which wouldn't get caught in the 1/1/2020 to 12/31/2020 period either. Shouldn't the custom quarter get translated to 1/1/2019 12:00 AM to 12/31/2019 11:59 (or 'less than 1/1/2020 12:00 AM'). What am I missing? Rick MacDuffie Symetra Life Insurance Company

[Doug_Den_Hoed__AtAppStore]

Hi Rick, I concur with your analysis, and agree that what you're missing is that last 24 hours. Worth raising as a ticket, and until then, given the "up to but excluding" behavior (perhaps As Designed) suggest you work around it by using: 1/1/2017 to 1/1/2018 1/1/2018 to 1/1/2019 1/1/2019 to 1/1/2020 1/1/2020 to 1/1/2021 Regards, Doug Doug Den Hoed - AtAppStore

[Rick_MacDuffie]

Thanks Doug. I actually thought of trying that and was immediately presented with a lovely "There are gaps or overlapping dates created by the highlighted date ranges." error/warning. Turns out that doesn't prevent you from saving the custom quarters and does yield the expected range. Thanks for getting me to look at it again and defy the Workfront UI's warning. Rick MacDuffie Symetra Life Insurance Company

[Doug_Den_Hoed__AtAppStore]

Attaboy, Rick: anarchy rules -- and makes a nice oxymoron. Such "boundary conditions" are notoriously tricky to code and test, so at your convenience, I'd suggest you raise a ticket to draw it to Workfront's attention; but with your workaround, suspect it might not make the hit list until some future quarter. Regards, Doug Doug Den Hoed - AtAppStore