Jeremy, what are the chances that option 1 "Custom Field Validation" can cover DATE fields as opposed to text entry fields? Or, would that feature include date fields?
Date validation is a near-universal want that would benefit just about every customer; whereas text validation would only benefit a subset of customers.
If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
Hi @William English‚ - I like it; tell me more... I hadn't originally thought about including date fields, but that doesn't mean we can't make something happen if we decide to move forward with this idea. 😉
Sure, users are generally surprised and disappointed when we tell them that we cannot enforce rules in date fields on a form. For example, date value must be equal to or greater than $$TODAY+3D; or prevent the user from selecting certain days of the week, or black out date ranges - just about anything that you could do with a date filter - plus the one thing that you cannot currently do with a date filter - specify weekdays. (e.g. $$TODAY+3D, but ignore Saturdays and Sundays when considering the 3D, so the earliest selectable date from a Friday would be next Wednesday, not next Monday.)
99% of the time they are trying to prevent users from selecting dates that are not within the scope of a SLA.
If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
Im going to go a little further with my take on ranked choice voting: I'd give them this order of importance:
(3) Projects Only from a Template
(2) Sequential Project Numbers
(1) Field Validation — I'm hoping this will be similar to "hashing" so I can ask for something like an Account Code in a specific format like "4 letters, 2 numbers, a dash, 5 numbers and dash, and a letter" or even better…allow for GREP pattern matching. Should be able to do "OR" in these pattern matches (for example, UPC can have a few different valid formats)
(4) Jump to Today — Honestly, every date picker I've ever seen has some variant of this…it shouldn't be in this list, it should be on some list of "basic things we forgot to implement at launch" to be done along with bugfixes and such.
Good to see someone looking into these QoL issues. :-)
Would the Custom Field Validation include Numbers? We have fields for department number and accounting codes that should be an exact number of digits, and though we specify in the Instructions ("enter the 7-digit department number"), users neglect to follow the instructions. Not a big deal, but would be great to have some add'l front-end validation as described.
agree this is a good call out @Elena Dooley‚ - and ideally, yes, it would include numbers as either part of the MVP scope or treated as fast follow-on work.
So many great things here! I voted but some notes related to our use cases
Sequential Project Numbers - this would save our resource person a lot of time
a "Jump to Today" option - surprisingly I haven't heard the lack of this as a complaint from our users, but I feel a large number of them would love this - I know I would. Especially this time of year when I am setting some things up for next year, often within a project that is used perpetually and was created a year or more ago.
Custom Field Validation - William's and Elena's use cases would be super helpful
Require Users to Only Create Projects from a Template - our project managers are pretty good about using templates (we even have a "No Tasks" template to be sure fields on the Overview that can be pre-filled are filled in and that all necessary custom forms are attached. But if I had this option, I would definately still use it.
The only one that is a big need for us is the sequential project numbers. The other 3 aren't important to our case use at all (but I see others need it).
Three of the four are very important to my organization. I voted for the project number being sequential because this has been the single most confusing thing for us since moving to Workfront this past month. We are receive around 500-600 hundred requests each week that all turn into projects and our volume will grow exponentially once we implement our next service lines. For our customers, they need a consistent tracking number from start to finish. So for us, it is more about one consistent number that can follow through from request to project but also increment 1 number at a time. We have already seen our reference numbers grow so big we have to add more characters to our archiving system to be able to handle the reference number.
The custom field validation would help us in date fields and when needing a specific set of numbers to be entered on a form.
The projects from a template feature would be very nice to have but we currently manage with training of our staff. As we on-board more people it gets harder to manage user by user so it would be nice to lock it down.
Great feedback and context @Kim Donkers‚, thank you‚. 500-600 requests a week is quite a bit, I could see how this could get confusing. Can you tell me more about the "consistent number"? Is it just a number or would you also need to be able to combine this number with other characters or codes (i.e. text or dates)?
I believe your ideal scenario describes how we would want this to function. So we would need it for both request and projects. Being that the system requires us to create a request first and before it can become a project, this would be ideal. If we didn't need to create a request first, then that would not be needed. We would need to set the starting point for the numbering one time and then should not need to reset it. We would want to have the number larger than any current number in our archives so they are not confused. For example, our old system ended around 390000. We would ideally like to start there.
@Amy Stella‚ Late to the party, but wanted to throw this out there:
Would the field validations throw errors in Kickstart? Currently we're having to manage macros on our spreadsheet to force these fields into a format we need once in Workfront. But as Workfront doesn't trigger an error for these things, and copy/pasting into the Kickstart doc can override macros, we are left with a potential for error. If the Custom Form has these "rules" in certain fields, it would be awesome if the Import would flag those issues with those fields, so that the user importing the info would catch anything missed on their sweep before it was in the system.
Thanks for your comment, Angie. This is an important consideration. Admittedly, there is still some "TBD" on this feature, but I'm going to include my colleague as well for visibility. CC. @Gevorg Kazaryan‚.
With the field validation, I would like to also be able to enter "other data" within rules.
Example, for a date field, I would like the ability to enter NA text to indicate the date isn't required. Right now we have to leave it blank. The same would go for numbers.