Removing the Subject field from the Request form | Community
Skip to main content
Level 6
May 23, 2019
Question

Removing the Subject field from the Request form

  • May 23, 2019
  • 76 replies
  • 10097 views
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!
This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

76 replies

Level 2
June 14, 2019
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
William--
Community Advisor
Community Advisor
June 14, 2019
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
If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
Doug_Den_Hoed__AtAppStore
Community Advisor
Community Advisor
June 14, 2019
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
Level 2
June 14, 2019
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
Heather_Kulbacki
Community Advisor
Community Advisor
June 14, 2019
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.
AileenTa
Level 5
June 14, 2019
I'm wondering why this didn't at least get posted to the Product Announcement section or posted as a product announcement? What is Workfronts process for notifying customers of changes? The last announcement I received was June 6th. > Aileen Taylor Cell Signaling Technology
Level 6
June 14, 2019
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
Angie_S
Level 3
June 17, 2019
I'm so glad to hear this is going to revert! Got my first request titled with someone's full (middle initial and everything!) name this morning, ha ha. Admittedly it's not someone that uses Workfront a ton but she is a repeat requestor so I find it interesting that she didn't question the field change and just charged ahead with entering her name. Happy Monday, everyone! Angie Simon CUNA Mutual Group
Level 3
June 18, 2019
Hi All Just to add our take on this, we have now had an influx of requests that have used their actual name in the name field. Again our requestors have minimal/no training in order to put a request in to us so even a slight change like this causes us issues with the quality of information we receive. A custom label for this field is what we require if we have no control over changes like this, or a calculated field based on what we are asking to be filled out on the form. Glad to hear it is being changed back in the interim. Thanks Jonathan Thain BT Group
Level 3
June 18, 2019
And I'd like to re-iterate and expand on what others have said - 1. This change should never have been implemented into the live environment, and it concerns me deeply that Vazgen, and presumably others have the ability to make this change without any further oversight, which should have stopped him when he proposed to deploy straight into live. What could have been the impact if this was a malicious insider attempting to damage the product? 2. What BT want (and it appears many others feel the same) is the ability to rename the Display name of ANY field to something which makes sense locally (we can do this in reports, so why not in forms) 3. Some method of generating an auto-created request name may be of use to some companies - but it must be optional and in control of the local administrator, as must the removal of the "Subject" field (or whatever the local admins have decided to call it in their instance) Most importantly I'd like to know urgently how Workfront are going to make sure this type of untested change cannot happen again Regards Bob Sleigh BT Group