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 get it, and trust me, I have a multi-volume manifesto called "Basic Things Workfront Should Do But Doesn't."
That being said, a mindset I would discourage is "we have to spend thousands of dollars just for Workfront to do this one thing that it should already do." That would only be true if you used Fusion to address that singular shortcoming and nothing else.
Instead, I choose to think of it as "we can implement dozens of features and automations in our instance that Workfront could never do for us, because the requirements are so customized to our environment and workflow that they wouldn't be useful to any of their other customers. And it only costs us a little bit more."
In the case of ref num sequencing, Workfront would probably release a feature where each object type has its own running sequence of numbers, and that would be it. It's still going to eventually reach 5 or 6 digits, or flip the odometer and start giving you duplicates. And, that might be okay for a lot of customers, but setting it up in Fusion opens up a ton of possibilities. Your own suggestion for how it should be implemented is a perfect use case for Fusion because you can tailor your serial number in exactly the way that makes sense for your company, but doesn't necessarily work for others.
And Fusion isn't going to do just your project sequencing. It's hypercapable of dozens of similar automations that without it, you wouldn't even consider because they're so labor intensive. (We personally manage tens of thousands of queue topics and routing rules that are generated by custom form values, with hundreds opening and closing each day.) Should Workfront do all of these automations without the extra cost? Sometimes. But a lot of what we throw at it isn't anything that I would ever expect Workfront to develop for us because it's so niche. So if we have it, why not use it to address those things that Workfront should do and just make our teams happy?
For every eyeroll and expression of disbelief I used to get because I had to say "sorry it doesn't do that," I now get a "wow, really?!" (in a good way) when I tell users about a new feature that we've built out to make their time in Workfront more efficient. It makes their life easier, which makes my life easier because I'm no longer the face of something that "can't" but something that "can do that and more."
I don't get anything out of promoting Fusion, I'm just a strong believer that for a little bit extra, it can elevate the performance of any instance. And, when customers use it to solve Workfront's shortcomings in a way that's perfect for them, that feature request becomes one less thing the Workfront development team has to do, so they can prioritize the things that Fusion can't solve - like Chapter 9 of my manifesto, "Custom Field Validation, or the the lack thereof"
If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
@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.