Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Requester (Primary Contact) Visibility In The NWE


Level 8

Hi all,

I have quite a few workers in my organization who have reached out to me to ask why Workfront got rid of the requester name visibility on the "front" of the issue page. (that right hand side panel that had the assignments, due date, status, requested by, etc.) Workers now have to scroll down to the overview section to find this information.

Does anyone know if there are any plans in the near future to add this to the top of issues? (I could see this being added to projects as well, but I understand that this was not something that was available in Classic previously) Screenshot attached to show where I think it could go in the NWE when viewing an issue. (or project)

I was so excited to show them that they now have the custom form on top and don't have to toggle between the overview and custom forms tab. But now that they need to scroll down to the overview area anyway, this makes this feature a little less valuable. It's not an extra click at least, but it's a big loss for our workers who relied on that requester visibility when on an issue page. I know this can be pulled into other areas like reports and Home, but having it available on the issue itself was important for our workers who work exclusively or primarily out of issues versus projects.

If this is already on the Idea Exchange can someone direct me to it? Is this a pain point for anyone else?




Topics help categorize Community content and increase your ability to discover relevant content.

10 Replies


Community Advisor

First of all, you're not wrong. The requester name is one of the things our org keys off a lot. Ideally this is something that would have had a prominent place on a request. I suspect a lot of customers probably have a lot of ideas about what should have a prominent place and this has led to quite a few of us feeling as though our important items have been passed over.

Secondly, you have quite a good fix already. You already have the custom form front and center. If it's important to you that the requester name be "promoted" (closer to the top), a good workaround is to put a custom calculated field in your custom form for the requester name. It's not as nice as Workfront providing is, but see above -- you're not wrong, but I wouldn't wait for them to do it.

Thirdly -- or another option for secondly -- I've mentioned in this other post ( that if you have a lot of stuff that you need to see at-a-glance, you could perhaps build a custom dashboard to house all of this and show that on top. On my screenshot in that post you can see I have who entered the original request as well as links to the custom form, but you can do anything you like. An option for this is having your custom form stays on top in the request details and this tab moved to the second position, and your custom dashboard has all the random bits of information that constitutes a better Overview, and is on the first tab. No scrolling, just clicking from tab 1 to tab 2 (also users who prefer tab 2 to come first can learn how to customize their view).


Level 8

Thank you Skye. I'm glad I'm not alone in this at least.

I like your idea of the calculated field on the custom form - but all I have the option for is Primary Contact ID. Do you have the formula I would need to display the Primary Contact Name?


Community Advisor

I don't keep that kind of stuff memorized -- but I can take this opportunity to show you two ways to find that information.

1) The best way!! Going to the API. Go to and change your API Version dropdown to "API Unsupported".

Now, enter "issue" in the filter. When the listing pops up, scroll down either the Fields tab or the References tab until you get to something resembling the Primary Contact. For primary contact, I would advise you to look at both tabs because it's important you get a bit more understanding around how this IS a field... but this particular field is ALSO a reference.

ALL the user information isn't stored on the issue object, but the user ID is, and that's what Workfront is going to use to reference the rest of the data you need. So for your calculated field, you want to know that it's a reference because that's what you'll be doing. You don't want the Primary Contact ID (which is the field) -- you want the reference so you can grab the rest of the info.

When you get the right reference, go ahead and click on the reference URL link, and scroll down those fields. Your calculated field would look like this: <Your Reference Name>.<The Reference's Field You Wanted>

For calculated fields, both of these words would come from the LEFT SIDE of the two columns. For valuefields/valueexpressions they would come from the RIGHT SIDE of the two columns.

For calculated fields they are separated by a period. For valuefields, they are separated by a colon.

2) The second way is what I call the lazy way. To find this kind of information -- just start creating a report. In your issue report, put in a column for the the primary contact name. Now, switch it to text mode. What does the valuefield say? That's your clue.

As I mentioned, if there is a colon in it, this is another indication you're not using a field on the issue object: you are referencing a field in another object. If you go this route, you can usually separate the words into actual words and capitalize them, and replace the colon with a period. (this is pretty lazy because you're just guessing what it should look like)

If whatever you guessed doesn't work, you would go back into the API explorer armed with the valuefield answer and look on the right hand column for this, and then refer to the left hand side to see what the calculation should have been. i.e. translate between valuefield and calculated field syntax using the API explorer.


Let's take a concrete example. I want to make a calculated field to show me whether the person who entered the request is still active. I'll look up "issue" in the API and scroll down the fields list until I find something plausible: Entered By ID, aka enteredByID. I'll look in the References tab for anything similar: I see Entered By, aka enteredBy -- so this is looking good. Clicking on the Entered By row, I can pull up the user metadata which shows me the "Is Active" field is on the user object. So my calculated field would be Entered By.Is Active.

I know you wanted a shorter answer! I kind of did as well. 🙂 But my goal for the year was to try and make more reporting gurus and fewer reporting questioners, so consider yourself moved over to the guru side of the fence, if you get this far.


Level 8

I consider myself pretty good at building reports and using some text mode that I have saved over the years, but I fall short on calculated fields / expressions on the custom forms. Most of what I need is typically there for me already, so I just have less of a need for them. So, I think this is a little over my head. I thought I might be on to something when you wrote about pulling the text mode from the report, but I'm not sure how this translates to the custom form exactly. In any case, thanks for the info and I'll try to keep at it as I have time.


Community Advisor

if you're already familiar with textmode in reporting and building reports, then you're really close, and I encourage you to persevere. Yep, go ahead and use step 2: pull the textmode from the report. If you have an issue report with a column that you want to convert to a calculated field, click on the column and switch it to text mode, and then locate the valuefield line.

If you see a line that says "valuefield=camelCase:camelCase" then know that you can guesstimate/translate that to "Camel Case.Camel Case" and that makes it a calculated field. If it errors out while you are building it, you probably guesstimated wrong, and can then take it to the API explorer to find out what the proper capitalization should be.


Level 8

so when I switch to text mode and grab the valuefield line it's valuefield=owner:name. this is where I don't know what to do when I want to use this in the custom form.


Community Advisor

if you see a line that says "valuefield=owner:name" then you know you can guesstimate and translate that to "Owner.Name". This would be your calculated field.

PS: In case people don't know:

  • Title Case All words are capitalized, except non-initial articles like “a, the, and”, etc.
  • camelCase Words are written without spaces, and the first letter of each word is capitalized.

Basically take what you see as a "camelCase" value in the valuefield line, and "title case" it. If there is a colon, swap the colon for a period. This turns many reporting valuefields into custom form calculated fields.


Level 8

0694X00000FTFBpQAP.pngAh, thank you Skye. I was putting valuefield= in the front. This worked, I appreciate your help!


Level 8

Quick follow up to this post - is there a way to hide the primary contact field I created on the form for everyone but our Help Desk team? I don't want our requesters to see it because it's not relevant for them. It looks like I can't hide a single field on a custom form that has been shared system wide?


Community Advisor

Long story short: I don't think you can hide one field in a custom form yet -- but read this link and experiment and maybe you'll find it can now be done.

I haven't played with this new functionality because it doesn't feel quite manageable. (Our users are just untutored "enough" that this would cause more questions than solve problems)

If this doesn't work, or doesn't work for you: in the olden days, we would put it in a section and hide the section from anyone who is just viewing. There are options for folks who are contributing/managing the object to be able to see more. The other option would be to have a section called "office use only" as generally Americans know to ignore that section. (if you're in another country, your mileage/kilometreage might vary)