Expand my Community achievements bar.

SOLVED

Change status relation for requests and projects

Avatar

Level 6

Workfront Community,

Does anyone know how I can change the status relation between requests and projects?

Our project status of Planning switches the request it's tied to back to New. When we convert a request to a project the request is automictically set to In Progress. We'd like to adjust the relation of the Planning project status to also keep the request set to In Progress rather than revert it back to New because it's inflating the number of new requests we have.

Thanks in advance if you where this setting is located at!

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

I suggest reviewing and comparing your status keys (PLN/CUR/CPL for projects, NEW/INP/CLS for issues). 

When tying a converted project status to it's originating issue status, the system first looks for an identical status key. If it finds an issue status key that matches the project status key, that's what it uses. Because the keys aren't identical by default, the system then falls back on "equates with" logic. So because there is no default PLN key for issues, the system selects NEW as the next closest match.

The best solution I have found is to create custom issue statuses that match every project status. E.g., make an issue status called "PROJECT: Planning" with a key of PLN and Equates with New. Uncheck all the request type options (Bug/CO/Issue/Request) and lock the status. This effectively hides the status from the status dropdown menu on the request and a user can never manually select "PROJECT: Planning" - but the system can use that status. This status makes it more obvious to the requester that the request has been converted to a project, that the status is now controlled by that project, and enables filtering the request from reports where status should only be NEW. 

For more details, you can reference this article and scroll down to "Synchronize the Status of the Resolvable Object with that of the Resolving Object." 


Good luck!

If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf

View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

I suggest reviewing and comparing your status keys (PLN/CUR/CPL for projects, NEW/INP/CLS for issues). 

When tying a converted project status to it's originating issue status, the system first looks for an identical status key. If it finds an issue status key that matches the project status key, that's what it uses. Because the keys aren't identical by default, the system then falls back on "equates with" logic. So because there is no default PLN key for issues, the system selects NEW as the next closest match.

The best solution I have found is to create custom issue statuses that match every project status. E.g., make an issue status called "PROJECT: Planning" with a key of PLN and Equates with New. Uncheck all the request type options (Bug/CO/Issue/Request) and lock the status. This effectively hides the status from the status dropdown menu on the request and a user can never manually select "PROJECT: Planning" - but the system can use that status. This status makes it more obvious to the requester that the request has been converted to a project, that the status is now controlled by that project, and enables filtering the request from reports where status should only be NEW. 

For more details, you can reference this article and scroll down to "Synchronize the Status of the Resolvable Object with that of the Resolving Object." 


Good luck!

If you like my content, please take a moment to view and vote on my Idea Requests: https://tinyurl.com/4rbpr7hf