Workfront

AnnaHolder · 7/18/24

When we convert a request to a project, its default status is set to Planning. According to this documentation, this means the request will remain in a New status. How can we change this? For example, if we wanted the request to go to "In Progress" when the project is in Planning. The documentation gives a handy chart of the synchronized statuses, but doesn't say how you can change them. TIA!

Overview of Resolving and Resolvable Objects | Adobe Workfront

KatherineLa · 7/19/24

This takes a little extra setup to make work, here's how I did it in our environment:

On the Issue side, I've got a set of custom Statuses set up. They're named things like 'Project - Planning', 'Project - Current' etc. I've got one created for each of the possible possible Project status values. The trick to making it work is the 'Key' value for the Issue-status. It's got to match the 'Key' value for the paired Project-level status. The screenshot below shows my 'Project - Planning' one with a Key of PLN since that's the key value for the Planning status in my Project setup.

In my case, I also only wanted Workfront to use these statuses and didn't want to confuse my end-users, so I created the statuses and then promptly locked them so nobody can see them. Workfront still uses them to update the Issue status, they just don't show in drop-down menus for my end-users. The only minor, but manageable, pain point this last step causes is in reporting. The locked values also won't show up when you're trying to build Issue-level reports, so you have to get clever there.

View solution in original post

KatherineLa · 7/19/24

This takes a little extra setup to make work, here's how I did it in our environment:

On the Issue side, I've got a set of custom Statuses set up. They're named things like 'Project - Planning', 'Project - Current' etc. I've got one created for each of the possible possible Project status values. The trick to making it work is the 'Key' value for the Issue-status. It's got to match the 'Key' value for the paired Project-level status. The screenshot below shows my 'Project - Planning' one with a Key of PLN since that's the key value for the Planning status in my Project setup.

In my case, I also only wanted Workfront to use these statuses and didn't want to confuse my end-users, so I created the statuses and then promptly locked them so nobody can see them. Workfront still uses them to update the Issue status, they just don't show in drop-down menus for my end-users. The only minor, but manageable, pain point this last step causes is in reporting. The locked values also won't show up when you're trying to build Issue-level reports, so you have to get clever there.

AnnaHolder · 7/22/24

Hi @KatherineLa, thanks for this! Wow, what you shared makes sense but I do see how it could get tricky. We've been talking about the possible need for custom statuses on requests and projects anyway, so the method you're using could fit in nicely for us.

Are your custom statuses on Issues set specifically on the "Request" type? I assume by your instructions that this is where I'd need to go, but would like to confirm. (Screenshot below)

Also, you mentioned that your custom statuses are hidden from the dropdown menu for your end users -- Does that mean that users also can't see the statuses when looking at Issues on a project? For example, if our PMO director wanted to see the status of all open Requests on our request queue project under the Issues page, would she be unable to see the status of issues that are using a custom Status? (Hope that makes sense)

Thanks again!

KatherineLa · 7/22/24

In this particular case, because I don't want the users themselves to be able to interact with the options, I have them unselected for all Issue options as below. That's what causes them to be Hidden statuses. I do that configuration under the 'Master List' and then nothing shows at all if I were to go to one of the other four tabs.

From the user perspective, the Status of the issue still behaves the way I want, see the second screenshot. But if they go into an Issue and interact with the Status dropdown, none of my custom options are available (third screenshot).

For displaying the data later, your PMO Director would be able to see the options just as my first screenshot demonstrates. What does get complicated is trying to build filters in reports though, since fully disabled options don't show up even to an admin for selection.

I'm going to respond with a build on a second post because I just had an idea that fixed my objection above. This is why I like these forum discussions.

AnnaHolder · 7/22/24

All of this makes perfect sense, thanks for explaining and providing screenshots, very helpful. How did you change the Key? It looks greyed out in your first screenshot, and it is for me as well when I try to edit an issue status.

Unfortunately I don't have the ability to select/unselect the various Issue types from the Master List (see screenshot). I'm not sure if this is because you can do that only on custom Statuses, or if it's because I'm only a group admin and my system admin has this ability turned off for me.

KatherineLa · 7/23/24

Once created, the key and 'equates with' settings cannot be changed even by the full admin. Your only option is to delete and start over. Mine matched because I knew what I needed them to be when I set them up originally.

Your guess on the Group Admin is likely also correct. As our instance-admin, I can set the System Status level to 'Lock for all Groups' so that Group Admins cannot edit the status. That's likely what's true in your case. It's not specifically /you/ that can't edit, it's anyone other than an instance-admin. There can be some pretty dramatic consequences to editing without understanding how the changes cascade across the instance.

That said, what you're trying to accomplish isn't unreasonable. I'd ask your instance admin to talk about it and see what they think of the idea.

AnnaHolder · 7/24/24

Ahh, wow, that is a big implication - That we'd have to essentially delete and re-create the statuses in order to sync up the Key with projects. This definitely would take collaboration with my instance/system admin and possibly other group admins as well. This is getting to be more complicated than I had hoped. I appreciate the additional insight!

Thanks for confirming on the Locked statuses.

KellieGardner · 7/23/24

What browser are you using? Your entire view looks to be off in that screenshot so I feel like something is off in the browser window. Notice the Name/Description, Equates with, Key etc headers above the new status box.

AnnaHolder · 7/24/24

Hmm, I didn't notice that, but I see what you're saying. I believe my screenshot was from Firefox because it's my default browser, but I just went to the same spot in Edge and Chrome and it looks the same. Is it not just leaving those column headers to align with the text beneath? Does yours look different? Here's a bigger screenshot:

KellieGardner · 7/24/24

Mine pushes all those headers below the new box for both me as a system admin and when my group admins do it. I'm using Chrome.

Might be worth clearing cache and cookies and then trying again? Otherwise, might be a bug and support can look into it because I feel like you should definitely be able to see those boxes. Are you able to see the check boxes on existing statuses if you try to edit them?

AnnaHolder · 7/31/24

Thanks for the screenshot. I cleared my cache/cookies and mine still looks different from yours. Notably, the checkboxes on the lower right are missing. I'll check with my system admin to see if this is something they can enable, or to confirm if it's a bug.

Thanks again!

AnnaHolder · 7/31/24

Oh, wait. @KellieGardner, I think your screenshot is what you see after clicking the "Add a New Status" button, right? If so, then I think I have what I need there; the check boxes for the 4 issues types (Bug Report, Change Order, Issue, Request) are all there.

Should I see those 4 check boxes when I edit an existing status, or only when creating a new one? (I do not have them if I edit an existing status)

KellieGardner · 7/22/24

We do this in our instance in a similar setup to Katherine and you align them by Key. There use to be a really good article on experience league about this but I just searched and couldn't find what I read previously.

Some considerations.

Only one object can use the Key. So, if you have multiple groups setup in your system with different settings and a group creates the custom statuses with the key for just their group then it doesn't get inherited UP to the system settings. So in the future no other group can create a status that maps and use the key.
- We have different group setups so what I did to get around this was to create the mapping for the standard statuses, like planned and complete, at the system level but any custom statuses for the group can be done at the group level.
For reporting which i recently learned from support is that if the status is "hidden" and equates with complete when you use the filter "is complete" = true/false then it doesn't include hidden statuses.
If you have multiple groups there isn't a way to really easily report on statuses they have created so I suggest creating some really good documentation around this for your instance if you create custom statuses that map.

AnnaHolder · 7/22/24

Thanks @KellieGardner for your feedback! I think I understand what you've described as a limitation with the Keys; that is good to know, appreciate the word of caution there. It sounds like the workaround you're using could work for our instance too.

KatherineLa · 7/22/24

Responding again with a build that I didn't want to confuse with another post -

In my original design, I created my custom Issue statuses and then disabled them for all four Issue types in my instance. This was meant to hide those options from end-users, to allow only WF to set them automatically. See screenshot #1. This had a cost in functionality though, since those values being hidden for all Issue types also completely hides it in the Report menus even from me.

In the discussion here, it occurred to me to wonder what would happen if I allowed the custom Status to be visible - but only to an Issue type that was NOT one used in my instance? Turns out I get the best of both worlds. When I interact with the Status options on an Issue with a type 'Request', the 'Project - Planning' status is not visible. But when I go into Reporting, I DO see that option in the overall drop-down now that I've told WF it should be available for Issues with a type of 'Change Order'. See screenshot #2.

In my instance this works because A) We happen to have an Issue Type that's entirely un-used, and B) I don't have a requirement to prevent the status from being visible in reporting.

@KellieGardner Might this fix your 'isComplete' challenge you mentioned too? I hadn't run into that yet, this hidden status setup is fairly new for us so thank you for pointing it out.