Feature update: Allow for tickets in a custom solved status to be excluded from default close automation

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)

As an admin, I am unable to use the status category solved for a custom status without it also being swept up by the default solve>close automation. The default solve>close automation should be editable to use either [status category][solved] or use the condition [status][solved]  BUT NOT [custom solved]

What problem do you see this solving? (1-2 sentences) 

We want to track some tickets that are effectively solved and allow them to be written to - ie not read-only. We are using a custom status for these tickets. The default solve>close automation closes tickets in the solve status category, not just with the standard solve status. 

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)

Currently, applies to any use case where resolution time is an important metric. To accomplish our goal, we need to categorize the custom solve in the pending category.

Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)

To accomplish our goal, we need to categorize the custom solve in the pending category. We could also update the standard [status category: solved] automation to some way out number like closing in 365 days instead of 4, then adding a new automation that closes [status: solved] after 4.

What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)

In the same way you can edit the time-since-solved, allow the default solve>close automation to be edited from using [status category] as a condition to just [status].