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

Using Request-Channel-Type in automation condition

bjones_62grxz

I want to capture the info for how tickets are submitted in our ticket reports. I know that you can include request-channel-type in JQL so I was hoping I could fill in a single-select custom field with the correct channel type using an automation when a ticket is created.

I was hoping I could potentially use a smart value like {{issue.request-channel-type}} to create if-else conditions in the automation. Both that and {{request-channel-type}} don't return anything (checked using automation's Log Action),

The only other solution I can think of at the moment is using a scheduled trigger to make use of the request-channel-type in JQL and then update the custom field that way.

JQL I'm planning on using for schedule trigger: project = {{project-key}} AND request-channel-type = {{type}} AND "{{custom-field-name}}[Dropdown]" is EMPTY

I'll have to make a different automation for each type which is kind of annoying but seems like the only way I can do this. I'm also open to using the webhook functionality in automation to access info from the API but I don't see it listed anywhere in the documentation: https://developer.atlassian.com/cloud/jira/service-desk/rest/intro/.

Anyone else have any experience trying to incorporate the Channel Type into other fields, automations, or workflows?

Accepted answers

Fernando Eugênio da Silva

@bjones

If you intend to use the request-channel-type as IF/ELSE conditions, why don't you just try using the JQL Condition feature itself to map this.

For example:
request-channel-type = jira
request-channel-type = portal
request-channel-type = api
request-channel-type = email

These are types of values identified by the request-channel-type and you don't need to input the channel value in a custom field, jira already consumes it natively in its base.

But if you really want to fill a selection field with the channel value, do it like this:

JQL condition: request-channel-type = portal
ACTION: Fill the custom field XXXX with the value: Portal

using IF/ELSE condition.

Forgive if I lose something. And I hope this help you.

All comments

Fernando Eugênio da Silva

@bjones

If you intend to use the request-channel-type as IF/ELSE conditions, why don't you just try using the JQL Condition feature itself to map this.

For example:
request-channel-type = jira
request-channel-type = portal
request-channel-type = api
request-channel-type = email

These are types of values identified by the request-channel-type and you don't need to input the channel value in a custom field, jira already consumes it natively in its base.

But if you really want to fill a selection field with the channel value, do it like this:

JQL condition: request-channel-type = portal
ACTION: Fill the custom field XXXX with the value: Portal

using IF/ELSE condition.

Forgive if I lose something. And I hope this help you.

bjones_62grxz

Hi @Fernando Eugênio da Silva

Thanks for getting back to me same day. Apologies that I didn't see it sooner.

I did end up filling in the custom field using a scheduled automation that uses a JQL search to fill it in.

The reason why I need to do this in the first place is because there's no way to export Request Channel Type as a column for reporting (as far as I can tell). This is why I ended up using the custom field that can be toggled on in my searches and then exported into CSV. Does that make sense?

Is there some other way to include the native attribute in a report?

Fernando Eugênio da Silva

@bjones , no worries, hope u good

You are right to use a custom field, in fact for export we can't get this value through the Jira interface as a column.

Have a nice year

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