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!
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
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
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
If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf
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 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
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
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 came here to say the same thing as Barb: users are going to enter their own name on every request. Sorry for any misunderstanding you got from my survey answer: it was never my intent to indicate that "Name" was a satisfactory title for the request. -skye
I laughed out loud when I got @Barb Pilarski 's message :) How true. Anyway, could the fix be as simple as calling that field 'Project Name'? I know that would fix it for my organization. Just a thought, @Vazgen Babayan ! Brandon Hamm Bravo Group
