Removing the Subject field from the Request form

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.

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

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.

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

I like this idea as well.

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

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.

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

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

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