I created a project report that is grouped by the Converted Request Originator's Home Team ID, and then I edited the text mode code to display the home team name instead of the ID, which worked. However, in the Summary tab, the data isn't broken out into separate sections by home team ID/name, it just says "No Value." I'd love to be able to display each home team and the number of projects submitted by each team here. Hoping someone can help! I've attached some screenshots of the report and the Summary tab, and here is the text mode code I used:
Grouping text mode by home team name:
group.0.linkedname=convertedOpTaskOriginator
group.0.namekey=view.relatedcolumn
group.0.namekeyargkey.0=convertedOpTaskOriginator
group.0.namekeyargkey.1=homeTeam
group.0.namekeyargkey.2=name
group.0.valuefield=convertedOpTaskOriginator:homeTeam:name
group.0.valueformat=string
textmode=true
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Honestly, this kind of thing is better if you just put it on the user object. One of the key tools for a system admin is to apply a custom form to all user profiles. This Home Team Name field would go on that user form and hopefully the calculated field is very easy to build on that user form.
After you apply this to the user, you'll find that the calculated field is then available for you in the converted issue originator list of fields.
Why it's a key tool -- As a side effect of putting it on the user, it's also available in a lot of other reporting areas, e.g. project owner home team, task assignee home team, etc. Whereas if you put it on the request form itself that doesn't help anything except for the request form in that workflow. As a bonus for your particular use case, the information does not need to be updated across existing forms.
@Kyna Baker - inactive‚ #quick-tip-idea + what are the most useful fields to put on a user profile?
Hi - unfortunately, once you change the groupings in text mode, you can't use the summary tab or charts. :(
Hoping someone has a solution for you for what you have now.
Something to help in the future (and sorry you can't do this retroactively), but on the original request, have a calculated field that captures the Owner.Name and Owner.Home Team.Name. Then on the project form, put those same calculated field on but leave the formula blank. When you convert from request to project, the value that populated the request will move to the project form as well.
Thanks Anthony! I think I'll go ahead and try this method out. I'm a bit rusty on creating calculated fields. If I wanted to display the "converted request originator"s home team name, do you know what text I'd use in the calculated field? I've been scouring Workfront's documentation but I can't find any resources on basic calculations like this.
Views
Replies
Total Likes
Unfortunately, I do not know how to do that. That is why I mentioned I've done the calculated field on the request and transfer that info during conversion. :(
Fingers crossed someone knows how to get o Converted OpTask Originator into a project calculated field.
Views
Replies
Total Likes
Honestly, this kind of thing is better if you just put it on the user object. One of the key tools for a system admin is to apply a custom form to all user profiles. This Home Team Name field would go on that user form and hopefully the calculated field is very easy to build on that user form.
After you apply this to the user, you'll find that the calculated field is then available for you in the converted issue originator list of fields.
Why it's a key tool -- As a side effect of putting it on the user, it's also available in a lot of other reporting areas, e.g. project owner home team, task assignee home team, etc. Whereas if you put it on the request form itself that doesn't help anything except for the request form in that workflow. As a bonus for your particular use case, the information does not need to be updated across existing forms.
@Kyna Baker - inactive‚ #quick-tip-idea + what are the most useful fields to put on a user profile?
This is great advice! I'm not sure how to apply a custom form to users. Could someone point me to a resource/documentation on how to do this? Very appreciative of all the helpful responses! @Randy Roberts‚
Views
Replies
Total Likes
it might be just a misunderstanding of my quaint language? When I say to "apply a form to users" I just mean attach a custom form to the user object. You would treat this the same way you treat a project/s that is missing a custom form. Just bulk edit and add/attach the form to all that need that form.
I'll add that to the list! Thanks, Skye!
Ah. We've never created custom forms for user objects, so this is new to me! I'm able to add a calculated field for Home Team ID, but what is the text logic I would use to make it display the Home Team Name instead? I'm pretty rusty on calculated expressions. Thank you!
Views
Replies
Total Likes
Ah I think I might've figured it out. Is it as simple as Home Team.Name?
Views
Replies
Total Likes
Update: After some research, trial, and error, I've successfully created the custom form for users and am able to report on the home team name/home group name! Thank you all so much for helping me with this! I do have another question now that I've created the user custom form: Is there a way automatically attach this user custom form to new users as they are created?
(My company uses single sign on, so users' profiles are automatically generated when they navigate to our Workfront instance). Thank you all again so much for this help!
Views
Replies
Total Likes
ADVANCED, PLEASE SKIP!
====================
To circle back to Anthony's original comment in case anyone is still stubbornly holding out for a project field, it is possible to get the converted optask originator's home team name onto the project custom form. The tricky part is in the nomenclature (at least, as far as I can tell). We had renamed "issue" terminology to "request", so we were finding that "Converted Issue Originator" would not work. I can confirm that Converted Request Originator fields are allowed syntax (in a calculated field) for us, and Converted Issue Originator fields do not work despite being listed out this way in the API explorer.
But quite frankly, I am really surprised that this works the way it does, since terminology is set by layout template. I am also worried that if we ever change terminology, this field will cease to work. I'm also confused by how it will work for people not on our layout template.
Anyway, long story short, I'm not going to bother to share the calculated field calculation with anyone, since it uses our in-house terminology which may not be the same as yours. Also, if you are getting different results in Preview Sandbox vs Production, yes -- that is a thing. Don't bother testing in sandbox.
Views
Replies
Total Likes
Thanks Skye, we have a form on every user object with home office, employee ID, available PTO, manager name, manager hierarchy, department/business Unit, and check boxes for company trainings they've attended. This has been incredibly helpful for situations such as the OP's.
I would encourage everyone to implement this.
Views
Replies
Total Likes