Removing the Subject field from the Request form

Hi everyone, Thanks again for all the feedback! The goal of the change was to reduce confusion yet it appears that we introduced more of it. Thanks for your active participation and monitoring the situation with the end users as well. We will revert the change next week and I will continue investigate potential solutions to this problem within the general research towards enhancing work intake experience. If you wish to connect with me on that research topic, here is my Calendly link that can be used to schedule a call on my calendar directly: "https://calendly.com/vazgenbabayan/feedback0dot5h" Link Thanks,"https://calendly.com/vazgenbabayan/feedback0dot5h" Vazgen Babayan Product Manager Workfront

Thank you William! I'm saving these two tips. I always struggle on the rare occasion that we use the Announcement Center when it comes to who to send to. Your method is genius! We use descriptive text for some of our custom fields, but I hadn't thought of it (or previously felt I needed it) for the default fields at the top of a request. I may even use the Request Queue Project's Description field on the overview tab to add a note about this field right at the very top of the request. I feel like the majority of my users wouldn't go back and change what they had already entered in that field once they come to the descriptive text down in the custom fields.

Can we please get the "Name" field reverted to "Subject" - or as others have already suggested "Request Name" or "Request Title"? Most requests we are getting today have the submitter's name in that "Name" field! Lots of rework - this has become my whole day's work, instead of actual work. Felicia Browell FedEx Ground

Sage and constructive advice, Sir William. Duly knighted. Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

Wow, it's hard to believe that a single word in the platform could cause this much response, but here we are! I voted twice - once for Title (since I previously suggested that as an option) and again for Request Name (which is perfectly fine). Like most admins, I'd love to customize this term on a per queue basis, but we've gotten this far without that feature, so I don't mind waiting a little longer. I've pulled a report of all new issues entered yesterday. Out of 70 requests, three users entered their own name in the field and the rest followed our naming convention. Ideally it would be zero, but I would not say the sky is falling... I will take this opportunity to share my advice for managing this kind of change: 1. Use your Announcement Center to announce changes! We have a little over 2000 users, most of them requesters. I don't want to send an email to someone who made a single request eight months ago, but I do want to communicate changes to more frequent requesters. So in the People section, I find all users who either haven't logged in more than 3 months, OR have never logged on more than 5 times. I select all, then turn OFF their notification preference for "A message is sent to the Announcement Center." Then I find all users who have logged in at least once during the past month, or more than five times ever. For them, I turn ON their notification preference for the same event. Then, I can send a message to "Everyone" in the Announcement Center describing the changes that are happening, and in this case, it went to about 600 of our 2000 users. This doesn't solve world peace, but it is a proactive step that will help reduce confusion when presented with change, at least for some users. 2. Preface your custom forms with descriptive text. "Subject" was never a perfect name for the field, so I start forms off with descriptive text that tells the user, "In the 'Subject' field above, please enter the ______________ for this request (where _________ is the ideal name for the field). And, I can add details about the request in general, typical SLA, which documents should be attached, and any other information to help the user correctly submit their request. With this change, all I needed to do is update that descriptive text to say, "In the 'Name' field above, please enter the _________ for this request. (Don't enter your own name, we know who you are üòÄ)" I know several admins who already takes these steps, and I'm not suggesting they solve this issue entirely; but certainly it helped to restrict the amount of confusion in our instance down to about 4% of requests; where it could have been much higher. William English T-Mobile

Vazgen, I'm less concerned about this particular change (since it's rather small) but more concerned with the general direction of updates being pushed into production without much notice as of late. In retrospect, perhaps it would have been more appropriate not to roll out this feature into production (regardless of how small it is) if there was little to no consensus in responses on the form you sent out. Personally, I feel like the dev team should focus on other areas of the request queue functionality than the removal/changing the label of the "subject/title/name" field; here are a few things that I think could use a bit of a rework: Publish settings setup (expand available options to specific teams/groups/companies) Reconsider the significance of request type selector (I do not understand how this is relevant especially since system admins cannot add custom request types) Add an option to make system fields mandatory at request submission Add the option to associate the same queue topics with multiple topic groups Expand the options available on the the routing rule setup: 1. add ability to assign to multiple users without having to resort to team assignment; 2. if routing to another project is selected, add option to place the request into a specific status/queue topic Thank you, Andrey Popov JLL

Vazgen, I think you meant well trying to get out a quick fix, but you tripped-up in three places: You violated the long-standing procedure of NOT doing knee-jerk feature requests. Such changes should always follow the Preview/QA process so you can get feedback instead of panic from people expecting to review it. Not sure why you felt it was so urgent to make a change that made barely anyone happy and most people probably weren't aware of. Seems like no one wants the quick fix: they want the actual feature request of "we get to name that field what we want." Seems like otherwise we're all already resigned to using the "Subject" name because at least we're used to that and have trained to that. I'm still doing implementation and haven't deployed yet and this confused my limited testers; I can only imagine what this did to a bunch of live users in a deployed instance...yipes. Remembering that Requestors are often barely trained, untrained, or creatures of habit. "Name" may make sense on the backend, but is super vague or too associated with another value (requestor name, project manager name, project name, request name, etc.) to be clear to a novice. To borrow from The Giver : "Specificity of language...". Which is kinda why we want to customize "Subject" to our own local needs (because that is kinda generic, but less so than "Name"). This is basic CX/UX stuff. Kevin Quosig

This is exactly what happened to us. The power users who are already familiar with and submit multiple requests a day, didn't pay attention to what the field was even called. They know what needs to go in that location. However, there were a couple of people who only submit once a month, and those are the people who put their own name in the field. I was trying to create a report yesterday to track and locate these changes (tracking and searching for "updated Name to" in the updates through a Notes report) but as it turns out, I can't report on those (they don't show up in Note Text or Audit Text fields). I was hoping to be able to have a near-exact number on here, but will have to rely on anecdotal evidence from users. I predict that if unchanged, this will just be one of those problems that will be noticeable every time we onboard a group of new requestors. We'll have to develop training or (more likely) track individual users down and remind them every time, what to put in the field. It's a pity because for the most part, most requestors try to avoid training, and rely on Workfront to be as intuitive as ServiceNow or other request-type applications. -skye

I like Angie's suggestion, that would work for my team. Aileen Taylor Cell Signaling Technology

I agree with Mark, I feel with the change we need to update all our process documentation, especially for those less-frequent users, to include specifically what we'd like to see in that field. We never gave them specifics for that field before and most users seemed to provide adequate information there. Although from the comments above, it sounds like that's certainly not the case for a lot of others. I talked to someone yesterday and some of their users try to fill in paragraphs of information in that small field.