Removing the Subject field from the Request form

Hi everyone, Thanks for all the feedback and votes! As a result of this, we will rename the Subject field to Name for a short-term solution and will continue research for the long-term solution of defining your own naming convention using custom field information. Thanks again! Vazgen Babayan Product Manager Workfront

I think changing the name of the field to something like 'Request Name' would be helpful and more indicative of what it represents. For both subject and description, admins should have the option to hide them or make them not required. I don't think WF should remove them. I agree with the points made in this thread about the issues autogenerating a request name could cause. A number or the portfolio name doesn't give me any indication what the request is about without having to dig through the custom form and wouldn't differentiate enough from all the other requests for the same portfolio (or whatever the autogenerated naming convention is). We only use one request queue- in which our users can request multiple related deliverables from a single request form. I then create a project for each deliverable (video, web, social, etc) by copying the first project I create and renaming it to easily identify which deliverable the project is for. So it's unclear how linking the field to a custom form field would work for us since often times the request is for more than one thing. We haven't had issues using the subject field. If changes are made to how the subject line works, I would need to be able to configure it myself for our instance (without limitations set by WF that would render it not useful). But even so, it could present some issues and I would definitely need the option to turn it off. Janelle Hicks Lifespan Corporation

I was originally excited for this but after really thinking about it, we would have the rename every single request that comes in. We have so many request categories, and get a lot of requests for each, and would not be able to tell them apart. We'd find ourselves in a situation similar to Brandon with hundreds of items that say "Web Graphic from Julia". If we can't rename it, we'd rather leave it as it is. Our users have gotten used to it at this point. Barb Pilarski Pittsburgh Penguins

Thank you @Vazgen Babayan for posting this here outside Ideas and for providing the survey link for feedback! Tammie Bouchard National Safety Council

Ditto. We'd have the same issue as Polly and Brandon. Also, agree with the ability to either rename the field, hide it or replace it with our custom field. Vics idea is intriguing. Our Requests go to our most finicky, aggressively critical team members which in turn would impact on using the Request feature at all. Forgo the Request feature and it significantly reduces the Workfront value to our department which I'd really hate to see happen just as I'm about to onboard this department. Tammie Bouchard National Safety Council

I recommended the same general concept Vic described - provide the same functionality as we have when creating calendar labels, using the variables of our own choosing; and customized on a per queue basis. That sounds like it's beyond the scope of what Workfront is able to invest in this feature request, due to some conflicting priorities. In that case, I would much prefer just being able to define my own alias for "Subject" in the Queue Setup tab. The other auto-naming options suggested don't have much value for our setup. William English T-Mobile

I agree with Polly. This isn't a desirable solution (I rated it low), and I'd prefer some ability to link the field to a custom field for that reason. Changing the label for other objects in the system (statuses, portfolios, projects) hasn't always worked really well, but I'd be open to revisiting it for this. -skye

I just filled that survey up. I agree with Brandon that I can't have "Primary Contact + "submitted a request for" + QT name appearing in my dashboards multiple times when the way it currently works is that the subject line is unique so I can quickly identify what that request is for. Don't take away the functionality we built our processes around that unique identifier. What was asked was the ability to change the label - agree with this. Others wanted to hide the field and maybe this is why WF is going down the route of automating the identifier, in case the field is hidden, we would still need it for notifications and other identification information. Again, we would still need the uniqueness of that identifier in notifications anyway. I don't want to receive 30 email notifications that John Sample has sent a request and I won't know what it was until I head back into WF. Polly Co

I agree with Skye. For myself, especially, as I'm constantly working with our projects and managing their assignments and workflows, this would actually cause significant issues. If I have a power user who submits 100 requests in a month, imagine how many projects would start out as 'Lorenzo - Print Request'. And for me to have to click into each project to see exactly what it is would take up an incredible amount of time (maybe I'm misunderstanding what's being recommended). For me and my team, we use 'Subject' as the Project Name. This is not only a quick-reference when viewing our reports, but it is a massive aid in searching for old projects. I also like what Vic mentioned. I think that being able to turn this function on or off would be really beneficial. Brandon Hamm Bravo Group

Hi Vazgen, I filled out the form, but thought I'd throw this out there for the long term solution. Instead of a standard format, allow it to be data driven and entered by us and allow us to have a different standard for each request queue. We use the API to rename most requests. For example, New Hire – [first name] [last name] – Start Date: xx/xx/xx Deactivate – [first name] [last name] – Emp ID [xxxxx] – Last Day is [yyyy-mm-dd] ... Hardware Request for – [first name] [last name] Where anything in brackets [] is a field from the custom form (or a native WF field). We can even maintain the original name and append to the end of it (instead of writing over it). Just a suggestion.