Jira service management and automation of sub tasks aren't working, fields or permission issue?

[Gil Erez]

I've been trying to build automation that when a service request comes in, tasks are created depending on the type of service request and some data within. My problem is:

1) Even transitioning the created service request doesnt work (No transitions were performed by this user.)  - error

2) Sub-tasks are created and linked properly, but cant have assignee and due date defined upon creation, nor can they be edited after creation automatically

(Edited work item successfully, however some of the set fields aren''t available. Fields ignored: {0}

Assignee (assignee), Due date (duedate)

No fields or field values to edit for work items (could be due to some field values not existing in a given project) - error

Ive manually given automation for JIRA permissions needed for the space, and the subtask scheme, screen, etc.. are all the same that I use for other regular JIRA spaces (all company managed). I'm on cloud version. 

[Marc -Devoteam-]

Hi @Gil Erez 

Can you provide a screenshot of your complete rule pls?

And what are the details per step in the rule?

[Gil Erez]

Essentialy its check one field if its >5 or <=5, transition the parent item one status, and create sub tasks so that staff can begin work on it

[Marc -Devoteam-]

Hi @Gil Erez 

Who is the actor of the rule and are there conditions or validators set on the transition to work in progress?

Does that rule actor have permissions on the project?

Second, on creation of the sub-taks, set the assignee and due date on the creation, not afterwards in a brnach.

[Gil Erez]

Updated so assignee and due date are aded on creation. Rule actor is automation for JIRA and it should by default be able to do things but just in case ive previously added browse/create/edit etc.. persmission manually to it as single user. Still get the same errors :( 

[Marc -Devoteam-]

Hi @Gil Erez 

Can you try to start a new rule and use the conditions set in the trigger outside the trigger and first try to only transition the issue, to in progress.

Lest dissect the rule

[Gil Erez]

When I change the actor of the rule to myself -- I get different error. The service request status is updated (yay) and the one sub task thats assigned to me is created and assigned with the correct due date. But the other 2 tasks assigned to another person fail to be created. I try to manually change assignee to that person but I cannot

[Gil Erez]

nvm that user had the wrong access on the atlassian side (was admin in JSM but didnt have agent access on atlassian) .. the rule 100% works now if I am the actor, not if automation for jira is

[Gil Erez]

I changed actor back to automation for jira and failed again. Added almost all permissions to single user automation for jira and failed again. Is it something with JSM that is blocking automation from being the actor and it must be me (space admin)?

[Anthony Morais]

Hi @Gil Erez 

Regarding the errors below, have you already tried the following?

- Transition error (“No transitions were performed by this user”)
That usually happens because the current status doesn’t have a valid outgoing transition for the automation user.
Try opening your workflow and, for the destination status, check the box:

Allow all statuses to transition to this one

This ensures the automation can perform the transition regardless of the issue’s current status.
Alternatively, verify that the automation actor has permission to execute that specific transition (no validator or condition blocking it).

- Sub-tasks: assignee / due date not being set
For this one, confirm that:

Both fields (Assignee and Due date) are included in the Create and Edit screens of the sub-task issue type.

The fields are also present in the Field Configuration and Field Context for that issue type and project.
If they’re missing in the screen or restricted by context, automation will skip them with a message like “Fields ignored”.

- Same principle for any other ignored fields
Yes — the same checks apply.
Whenever automation reports “some of the set fields aren’t available”, it almost always means the field isn’t on the screen, isn’t available in the field context for that issue type, or is being edited before the issue is fully created.
If that’s the case, you can add a short “Re-fetch issue data” action before editing fields.

Hope this help.

[Gil Erez]

Added transition any  to work in progress - still fails

Can confirm that the 2 fields to be edited are found in the screens and in the field configurations

Tried to shore it up and had re-fetch already before ... but still it fails:(