I'm trying to require agents define the "Requested For" user which is not required for customers on the portal unless they select they are submitting for another user. I've looked through the forum history, tried Gemini and Copilot, and haven't been able find anything that meets all conditions. * Requested For (User Picker) is required for agents * Requested For (User Picker) is required for customers IF Requesting For = For Someone Else The only way I can think of to do this is to identify if a ticket was submitted through the JSM portal or the agent-view Create button on the Create transition of the workflow. If there are any other suggestions other than setting it required later in the workflow, I'm happy to take suggestions.

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; } } }

Identify JSM Submission Type on Create Transition

Mathew Lederman

I'm trying to require agents define the "Requested For" user which is not required for customers on the portal unless they select they are submitting for another user.

I've looked through the forum history, tried Gemini and Copilot, and haven't been able find anything that meets all conditions.

Requested For (User Picker) is required for agents
Requested For (User Picker) is required for customers IF Requesting For = For Someone Else

The only way I can think of to do this is to identify if a ticket was submitted through the JSM portal or the agent-view Create button on the Create transition of the workflow. If there are any other suggestions other than setting it required later in the workflow, I'm happy to take suggestions.

Accepted answers

Marc -Devoteam-

Hi @Mathew Lederman

Simply said this is a process thing.

In my opinion agents should also use the portal to create tickets, this as you ask customer to provide specifics that are mandatory on the portal, but you can't set these options mandatory in your Field Scheme, as some fields might only be mandatory on answering another question first.

So instruct Agents to raise issues on the portal as well, as that will trigger that they are raising the ticket for another user.

Your only alternative is to add a screen from the initial status in the workflow to the next where you place the field and set a validator to make this field required.

All comments

Arkadiusz Wroblewski

Hello @Mathew Lederman

Problem with your Use case is, that property are populated after the work item has been created, so it isn't available reliably while a Create-transition validator is executing.

That need design change. Can you elaborate what your use case is? Maybe it just need simplyfying design or do that other way.

Best,

Arek🤠

Mathew Lederman

Arek,

The use case is for service desk incidents like "I forgot my password" or "I can't get access to Jira today, but I could yesterday".

Users can submit tickets through the JSM portal for themselves or on behalf of others. Service Desk agents take calls and chats where they also log tickets, but through the Create button where additional metrics are captured.

If a user is submitting a ticket for themself, there's no reason for them to select the impacted user. If a user is submitting for another user however, the impacted user is required. Service Desk agents should ALWAYS be required to populated the impacted user. Ideally, on creation to avoid missing this detail when the issue is being researched later.

Any ideas on how to work this so that we don't have to create duplicate fields, can require on create for agents, and allow customers to submit when appropriate?

Thanks,

Mathew

Marc -Devoteam-

Hi @Mathew Lederman

Simply said this is a process thing.

So instruct Agents to raise issues on the portal as well, as that will trigger that they are raising the ticket for another user.

Your only alternative is to add a screen from the initial status in the workflow to the next where you place the field and set a validator to make this field required.

Arkadiusz Wroblewski

Yep. Im also behind optimize process. And not always tools behind it.

Mathew Lederman

This makes sense except the users answer a very different set of questions.

Customers are asked

Type of impact - Access, Question, Escalation, etc.
Level of impact - Self, Team, Location, Global
Summary
Description

Agents are asked

Contact Method - (Email, Phone, Chat, Bot)
Requested By
Requested For
Summary
Description
Category
Assignment Group

I need to have some way to identify if a ticket was submitted by an agent or a user so I can't use the same form, but I could create an agent-specific JSM form that is hidden from normal users. This does add some complications, but something I could probably work with the team to find a solution.

Marc -Devoteam-

Hi @Mathew Lederman

Then a screen with a field and validator on the transition could help, this would be the simplest.

You could also JQL this.

There is the JQL function "request-channel-type" this differentiates on

portal
anonymousportal
email
jira
api

Abubakar Pokam Tchawa

The simplest approach is two separate request types — one for customers, one for agents. Since JSM defaults "Requested For" to the logged-in user, customers submitting for themselves don't need to change it. There is no native way to enforce "Requested For" as required specifically for agents, so the real solution is training: agents need to understand they must always fill it in. Ultimately, agents using the portal are themselves a form of customer, so treating them as such and relying on clear guidance is more practical than trying to enforce it technically.

Welcome!

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

Quick Links

Find more posts tagged with

jira-service-desk-cloud

jira-service-management-cloud

jira-service-management

admin