Is there a way to only show a specific status when a status has been renamed in other groups?

[AshleyMartinez]

I am experimenting with custom statuses for groups. 

At a system level, we have Current. For my groups XYZ and 123, I renamed Current to "XYZ Current" and "123  Current" respectively. 

Now when I run reports where I want to see projects with a Current status, graphs now show those names collectively at all times. So instead of the graph showing there are 7 projects in Current status, it now shows there are 7 projects in Current, XYZ Current, 123 Current status. 

So I suppose my question is twofold:

1) is there a way to show all projects but have them only appear as Current, since they are all the same status but some are just different names of the system status? so if 2 are in Current, 2 are in XYZ Current, have a graph show 4 Current (since Current is the system status).

2) is there a way to show only one of those statuses in graph form? so with the same example as above, if 2 are in Current and 2 are in XYZ Current and I only want to show those in XYZ Current. 

When I select filters, it lists all of the statuses on the same line because they are renamed versions of Current. 

Really would love some help on this one. Thank you!

[skyehansen · Accepted solution]

Not without use of calculated fields. If you would put a calculated field in your project custom form basically detailing all the statuses (e.g.

IF({status} = 'CUR', 'Current', IF({status} = 'PLN', 'Planning', '')) ad infinitum), then you could report on this.

In general though, customizing status names from group to group like this, just tends to open up a can of worms (in this case, the worm is that you now have to maintain a set of custom calculated fields to manage reporting on it).

[AshleyMartinez]

Thank you so much for the insight on this! 

Is the recommended course of action to add new statuses for each group rather than renaming system statuses? 

I have groups that absolutely want to deviate from the system status so I want to ensure I can setup the system and each group for success. 

Thank you again for your input! 

[skyehansen]

I'm not sure that there's a general "recommended" course of action.

For us, we have thousands of users and hundreds of workflows in Workfront. Imagine if everyone got their own special snowflake status.

And even if you only had ONE workflow in Workfront at the moment, I would STILL say "imagine what would happen if you merged with another company and suddenly had to put 200 workflows into the system -- what kind of precedents would you want to have set, previous to this moment?"

Also imagine how disorienting it might be for a user in such a company if they transfer from one team to another, and on team XYZ they're used to status XYZ but now they are on team ABC, and they have to figure out which status to use.

This is why our standard thought process and governance is "we keep the status list as short as humanly possible and we'll include all the other statuses you feel you need, on your custom form as another dropdown field." Our system status field is for all-up reporting across the whole system and to set up/activate/on hold/close a project. To communicate one team's "nuances" you can use your team's custom form.