Removing the Subject field from the Request form

I am getting a "resource unavailable" error message for the link, but can you make it so that I can tie the subject line to a pre-existing field on the custom form I use for that request queue? thank you! -skye

Putting myself on this thread so I can see when the survey link is updated. Very excited for this!! :) Anthony Imgrund FCB

I'm not too sure of this one. We are using the Subject field as an identifier that's both familiar to the requester and to the project team. Forcing a new naming convention might not be great for us, unless you are now adding an autonumber field and like Skye's request to connect to fields on the custom form. My other suggestion would to allow us to change the label of Subject - maybe via the layout. Polly Co

Hi everyone, Sorry about the wrong link, just updated it so it should work now. Thanks for all the points so far! Regarding tying it with custom fields, it will be a larger effort for us and since we are going to work on a greater initiative to greatly enhance Requests in general, that will be a part of that. This option we see as more of a short term solution for the problem üôÇ Thanks, Vazgen Babayan Product Manager Workfront

We have requests queues everywhere (many projects have a small queue), so just basing naming off queue topic + ___ may not be useful enough for us. I put in project name + topic group + queue topic. -skye

Yeah we use the API to rename our requests to a standard naming convention (and include variable custom form fields). So I can see this being super useful.

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.

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

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 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