How can I limit the approvers field in a team-managed JSM project?

[Cat Lewis]

We have a request form that requires an approver, but the correct approver is dependent on the state the request is coming from. Ideally, the requester would be able to select the correct approver for their state from a dropdown list that contains only the people authorized to approve the request. The built-in approver field that is generated when adding an approval step to the request type workflow allows the user to select from any user associated with the space.

I attempted to follow the instructions in the forum post linked here to add a custom user picker field with a filter, but I am unable to select that field (named Chromebook Request Approver) as the Approver field in the workflow editor.

I suspect this is due to the fact that our service space is team-managed, not company-managed. Is there any way to accomplish this in a team-managed space?

I am open to creating an automation with an if-else if that's what it takes, but I haven't found an easy way to apply conditional logic to the approver field either.

[Joseph Chung Yin]

@Cat Lewis 

Welcome to the community.  In our env, we don't allow Team Managed projects to be created and used anymore.  

I don't believe it can be done in a Team Managed JSM project setup.  Let me do some more research and get back to you.

In the meantime, you can also contact Atlassian Supports Team (https://support.atlassian.com) for their assistance too.

Stay tuned.

Best, Joseph

[Shreyas_Quietmill]

You've hit a genuine team-managed limitation - the workflow editor there only binds the built-in Approvers field to an approval step, and it won't accept a filtered custom user picker the way company-managed does.

Since you're open to automation, this pattern works in team-managed:

1. Keep a controlled dropdown on the request form - either your "Chromebook Request Approver" field or, better for compliance, a plain select list of states. Hide the built-in Approvers field from the portal request form so requesters never touch it directly.

2. Add an automation rule: When issue created -> Edit issue -> Approvers. If the form field is a user picker, set Approvers from it with the smart value {{issue.Chromebook Request Approver}}. If it's a state dropdown, use an If/Else block that maps each state to its authorized approver.

3. The approval step then runs against whatever the rule wrote into Approvers, so the requester only ever influences it through your controlled list.

Small design note: the state-dropdown-plus-mapping version is stronger than a filtered user picker, because requesters can't hand-pick a friendlier approver - the mapping lives in the rule where only admins can change it.

The alternative is moving to company-managed for the filtered-picker support, but that's a heavy migration for one field.

[Arkadiusz Wroblewski]

Hello and welcome to Atlassian Community @Cat Lewis 

Your Use case is Documented here [JSDCLOUD-13180] Adding Approver for Status in Request type Workflow, when Approver is of User Picker type, throws "Already exists. Try another name." error - Create and track feature requests for Atlassian products.

Also with some small Workaround How to update the Approver via an Approval field using Jira Automation in team-managed projects | Jira and Jira Service Management | Atlassian Support

Best.

Arek🤠