Expand my Community achievements bar.

Join us LIVE in San Francisco on November 14th for Experience Makers The Skill Exchange. Don't miss out on this free learning event!

I want to be able to rename Subject field

Avatar

Level 10

2/17/17

The label "Subject" is confusing for the users who are already typing it in a custom form. I want to be able to rename it to better reflect its purpose.

15 Comments

Avatar

Level 4

3/10/17

this is a very useful idea. even if you cant make it customizable at the admin level. simply naming it "job title" or "title" would help

Avatar

Level 2

3/14/17

Calling it "Request Name" would eliminate so much confusion! Every time I train on WF, I apologize for the fact that it says "Subject" when really, it's the title of the request a user is submitting, not the subject of a piece of creative. Franchisees get it wrong half the time.

Avatar

Level 1

1/24/18

I cannot agree more with this! Having the name Subject in this field is very confusing. As we are getting ready to implement this at our organization, I can already hear the question coming from Requesters on what should go in that field. Since they are filling out a request form it should really be the Request Name field, not Subject.

Avatar

Level 5

3/16/18

Yes! Please! We have had another client today ask for this... at minimum being able to hide this field or add a help bubble.

Avatar

Level 1

3/18/18

I'm not kidding when I say Every. Single. Client. has wanted to either delete, change or move the "Subject" box - at the very least, Workfront needs this label to be adjusted to meet the client's needs.

Avatar

Level 4

5/17/18

Its really makes no sense to me. Nowhere else in the system is 'Subject' used. Its Issue NAME, Task NAME, Project NAME. Why does the Request Queue have the terminology of Subject?

Avatar

Level 7

8/14/18

How about not making it required, either? Would be great if we could default the Request/Issue name to be one of the fields from our Custom Form. I know this is more advanced functionality, but it would be so much smoother for 95% of our use cases.