nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Jeremy Wood

Hello,

We recently launched a new ITSM project that now utilizes the Teams functionality within JSM. Our previous project did not use teams.

When a ticket is created, the customer selects an application that the ticket is for an an automation rule runs to assign the team based on the selected application.

The problem i am running into is when teams move tickets from our old project to the new one, they often leave team blank because it was not used in the old project.

I am looking for a way to make Team a required field but without adding it to the request type for customers to have to select when creating a ticket.

Is there an easy way to do this?

Accepted answers

Gabriela - LeanZero

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.

All comments

Karsten Gutjahr

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

Gabriela - LeanZero

@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/

Karsten Gutjahr

Just to be more precise: You can EITHER make field Team required in the workflow, OR alternatively build an automation, that adds an internal comment to the work item every time it is updated, but Team is blank.

Jeremy Wood

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.

Karsten Gutjahr

Is a default team an option? You could make the field required and use the default team in the creation process.

Jeremy Wood

A default team is an option. But i don't see a way to set that default team.

Team is a system field that doesn't seem to have a field context/default value option. And if i add it to the request form it does not have the option to hide with a default.

My existing automation triggers on work item created, and sets the team at that point. If I make the field required, customers have to select the field during creation which is not what i want.

Am i missing something?

Karsten Gutjahr

I can't find a source right now, but I remember Atlassian is going to roll out a feature which allows us to set default values for system fields. Maybe it was in context of the new Field Schemes.

Gabriela - LeanZero

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.

Karsten Gutjahr

Thank you for pointing out that trigger. You can avoid useless trigger by adding a condition inside the trigger.

That queue for empty Team is definitly an option, but I am afraid the OP has no one to handle that queue.

Gabriela - LeanZero

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.

Jeremy Wood

Would Field value changed trigger when a ticket is moved from another project though? That was the main reason i was looking to use the multi-action trigger. I suppose i could also create two separate rules if needed.

Jeremy Wood

Karsten is correct. I dont really have anyone to monitor the queue.

I actually have that setup today and monitor it myself, but that's not ideal as tickets sit in there until im able to catch them causing unnecessary delays for our customers.

Gabriela - LeanZero

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management