Make Team Required field without putting it on the request form?

@jeremy wood Karsten's pointing the right way, keep this in the workflow. Be careful with marking Team required in the field configuration though. A required field that isn't on the request form makes portal submissions fail, and the error only shows up in the browser console.

Add a Field Required validator on the transition out of your first status, not on Create. Your automation still sets Team right after the ticket is created, and the validator then stops anyone moving it forward while Team is blank, including the ones dragged over from the old project. Team only shows in the validator's field picker if it's a shared team from Plans and it's on the transition screen.

For moved tickets that just sit in the open status, keep a small automation that comments when Team is empty so they don't slip past. Atlassian's page on workflow validators covers the steps: https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-validators-for-company-managed-projects/

Hi @Jeremy Wood, I like to help.

So when the customer creates a work item, the field Team should not be required. But whenever anybody does something with the work item, he should fill in the Team?

Also you have a lot of old tickets Team blank? But whenever anybody does something with the work item, he should fill in the Team?

Is that correct?

You can certainly make field Team required in the workflow, using Restrict Transition Workflow Rules (Conditions). You can also build an automation, that adds a comment to the work item every time it is updated, but Team is blank.

Best wishes

Karsten

Field value changed on Team won't catch a move-in. Your instinct was right. That trigger only listens on create, edit, transition or assign, a move is none of those, and a ticket that lands blank and stays blank hasn't changed Team anyway, so there's nothing there for it to react to.

The Work item moved trigger you floated in your first post is the one that fits. It fires on the move itself, whatever the field values are, so it catches the ticket arriving in the new project even with Team empty. Scope it to the destination, check Team is empty, set your default.

The in-place case, someone stripping Team off a ticket that's already here, is where Field value changed on Team belongs. Two rules like you said, one per case.

The queue nobody watches, though, I'd handle a different way. Triggers only fire in the moment. A scheduled rule doesn't care how or when a ticket went blank, it finds them by state: run one daily on JQL like project = YOURKEY AND Team is EMPTY, set the default, ping whoever should know. Nothing sits waiting on you to spot it.

The counting works the way you said, which undoes my warning. A run only counts when it performs an action. Atlassian's usage page puts it plainly: if a flow runs but doesn't successfully perform an action, it won't count toward your monthly usage, and there's a worked example there with a trigger, a failing condition, and no charge. So a rule that wakes on every edit and stops at Team is not empty costs nothing against the quota. My pooled-limit worry doesn't apply. This flipped in the November 2023 packaging change, and I was still on the old rule where a bare trigger counted.

Two things still stand, for whoever builds it. The run is usage-free but not free-free, each fire still writes an audit-log line, so a project with heavy editing leaves a noisy trail. And there's a cleaner trigger for this than Work item updated. Field value changed, pointed at Team, wakes when that field changes and skips edits to anything else. Exactly the moment you care about. It carries a Fields to monitor for changes box where you name Team, so a summary tweak or a comment won't wake it. Work item updated has no such filter, which is why it fires on the lot. Atlassian's own optimisation guide even calls Field value changed the more economical of the two.

On the queue, fair, an empty-Team queue only helps if someone looks at it. Same as your comment idea though, both surface the gap and neither assigns it. Worth pairing either with the validator so the ticket can't move on while Team is blank.

Poking, since you asked. The logic is fine. The trigger is where it bites.

Work item updated fires on every edit of every ticket in the project, so that rule runs constantly. Automation runs all come out of one pool per product, and single-project rules stopped being exempt from it back in 2023. What should worry you is the cap. Hit it and every rule in the product stops until the month resets, including the create rule that sets Team in the first place. A safety net that can switch off the thing it protects is a bad trade, so look at your automation usage before committing to that trigger.

The default has its own edge. Auto-filling a team moves the ticket into that team's queue, so it stops being invisible and turns into someone else's, quietly, with a comment nobody reads.

For the fear you actually named there's a cheaper primitive. Add a queue whose JQL is Team is EMPTY. Queues aren't exclusive, an issue turns up in every queue it matches, so this one sits beside your team queues without touching them. Anything that loses its Team lands there the moment it does, costs no runs, and misfiles nothing. It won't stop the blanking. It does take forgotten off the table, and that was the part you were worried about.

Thank you for the answers. 

My main concern, is that all of the queues in the new JSM project are based on the team field. If someone moves a ticket without setting the team, or if they remove it when editing a ticket (without transition), we risk that ticket not showing up in any queues and becoming forgotten. 

Adding a workflow validator and even automated comments would certainly help limit this from happening. But i wouldn't remove it entirely. That's why i was hoping for a way to somehow make it required for all edits outside of the ticket creation sense customers do not set this field. 

I'm thinking my best option may be to setup an automation that triggers on work item moved, or work item updated with the condition team is empty. Then set the team to a default and add a comment stating to update the team if different from the default. 

Please feel fee to poke holes in this idea if you see any.