Removing the Subject field from the Request form

[Exp_-_VazgenBa]

Hey everyone, >Renaming the Subject field on the request form is currently one of the top-voted items for the Idea Exchange. We are currently debating an option to automatically generate incoming request names using a predefined naming convention and remove the Subject field from the request form altogether. There are several options we're thinking of for the naming convention, so your feedback will be invaluable for us to understand whether we are close with our hypothesis or completely off track. If you could please fill up the form below, that would help us immensely!

[Exp_-_VazgenBa]

Fair points. We have decided to go with the Name also due to consistency with project creation dialogue: In any event, the survey and the thread discussion clearly showed that there won't be one predefined naming convention that will work for all cases. The change should be live in production now. Please keep me posted on further developments and how the users use the new flow. In the meantime, I continue research on the larger initiative allowing you to set up your own naming conventions. Vazgen Babayan Product Manager Workfront

[Doug_Den_Hoed__AtAppStore]

Agreed, Vazgen: I was also going to suggest "Request Name". Regards, Doug Doug Den Hoed - AtAppStore Got Skills? Lend a hand! https://community.workfront.com/participate/unanswered-threads

[pco88]

Whoa... why is WF releasing things off schedule release dates? I don't believe the others who are not in the community or this thread would know about this change. I've been off for a while on the community and just had to come back for this. While I see most of our long time users a bit thrown off by the change there, I'm crossing my fingers that they're not putting their own name in there. I also think as the others do that it will cause our new users confusion and actually type in their own name. :( Polly Co

[CalvinFold]

"Request Name" or "Project Name" or even back to "Subject" because...people will enter their name. Ugh, I already went through the trouble to do a calculated field to map "Subject" to "Request Name" on my own so it shows properly on our custom forms...now this? Kevin Quosig

[SkyeHa]

Vazgen, I want to give you full points for trying to remain consistent but we're really talking about two different things here. Our Requestors get very different training than our Project Creators. Often they get no training. And when creating a project, you are presented with a completely different display than a request and it's easier to see the Project's name field in that context, vs the Request's name field. I'm concerned that requestors who have little to no training are going to be presented with a field that they will intuitively fill out with their name. -skye

[William--]

Thank you for the update, Vazgen. Given the feedback from the community (which I echo), I'd like to suggest that instead of Name , Workfront use the term Title . If consistency across objects is a high priority, I believe "Title" would work well to replace "Name" unilaterally on projects, issues, and tasks. Alternatively, I'm open to " Request Name " as has been suggested by others. Just my 2 cents... William English T-Mobile

[denise_moore_ameritas]

Oh my gosh...the sudden changing of the Subject field title to Name is causing us HUGE problems. Please tell me that it is being changed back or a better solution is coming VERY SOON!! Or am I missing a way that we get to choose the terminology for our own instance? Denise Moore Ameritas Life Insurance Corp

[SkyeHa]

hey @Denise Moore can you be more specific about what the problems are? Is it that requests are starting to come in with the user's name in the request title? Or some other problem? -skye

[denise_moore_ameritas]

Yes. Ugh. Sounds ridiculous I know...but, they are putting in their name...or the name of the person who is going to be the contact. Some even name and phone number. Some even the name of the person they think the request is going to. Ugh. If we cannot control our own verbiage and if subject is a problem for some, but some sort of "name" would be better for those people, then wouldn't it make more sense to be something like "request/issue name" as that is what is being filled out...a request/issue. Denise Moore Ameritas Life Insurance Corp

[Exp_-_VazgenBa]

Thanks everyone for the feedback and letting me know the results of the change! The outcome we want to drive is to increase clarity for what the field means, not make it more confusing to people. I want to ask all thread participants to let me know how users respond to the change - do all have the same problem as Denise mentioned? @Denise Moore , how widespread is it at this point? We can make the change fast, I want to ensure we are changing it to the best possible option though. On this note I wanted to ask will be the best label to use for this? Several of you have suggested Request Name as a suitable option. @William English also suggested the word "Title". I have built out a form with several label choices, can you please vote for the most clear ones? "https://forms.gle/wsDi6P2iv1H7ww4t8" Survey Link Thanks, Vazgen Babayan Product Manager Workfront

[Heather_Kulbacki]

I've been following along on this thread, not realizing it was going into Production so soon. I just sent a note to all my PMs asking them to keep me updated on what they are seeing coming in on new requests. My guess is that our regular users who submit all the time, will fill in that field as they normally do without even noticing the new field name. Our infrequent users (and we have a good number of them) who already need a lot of hand-holding though, will likely put their own name in there.

[AileenTa]

Hi Vazgen, Please don't fix it by making new problems! I do not want an auto-populated field that my team would have to deal with. Please just allow the user to rename/change the field to suit their needs. If the user wants an auto-populated the subject line field then allow the user to change it, if they want it to say "Project Name" instead of "Subject Line" then allow that. Aileen Aileen Taylor Cell Signaling Technology

[JillAc]

I get that the nomenclature within Workfront is to call everything "Name" but people who make Requests are quite often not Workfront users, so that nomenclature doesn't mean anything to them. It's fine for power users who are creating reports and filters, but for requesters, they are never exposed to those naming conventions. This is going to cause chaos for the people who have to action the requests and figure out what the request is and name each one. They already name things badly ("Send me 4 photos for an event" type of thing) but usually there is a big clue in the request name that comes in. Every form you ever fill out in life, from elementary school on, asks for Name, Address, Phone, Email. This is going to throw them for a big loop, especially because there we don't ask them to write in their name with their request, as it is auto-populated inside the Issue.

[Angie_S]

I would rather be able to customize this field name myself, by queue, if possible. We have a meetings team that want this to be called "Meeting Name", we have a request team that wants this to be called "Request Name", etc. Haven't seen any concerns with just "Name" yet but I personally just don't like it because it sounds like the person's name. That's what I would think upon seeing it if I had never filled out a request before. Angie Simon CUNA Mutual Group

[VicAl]

I like this idea as well.

[Centene_Portfol]

Hi Vazgen, Just to make sure it isn't lost in the shuffle - I think there is another concern about changes being made to our production instances without notice. If it were accessible in Preview and scheduled I would feel different, but as we may have our own training guidance and user interaction going on - this causes me concern. I think this is a far bigger problem than just whether or not this specific change is seen as a problem to a random survey of Community users' instance populations. Mark Lopez Centene Corporation

[Heather_Kulbacki]

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.

[AileenTa]

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

[SkyeHa]

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

[CalvinFold]

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

[AndreyPo]

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