I have an automation running in my company that clones a specific service request ticket into a Kanban project.
Now I’m having trouble transferring the assigned person to the cloned ticket.
I have a custom field in the form with a few options. Depending on the selection, the ticket should be assigned to a person. It all works, but the assigned person is only set in the original ticket.
To better understand what’s going wrong, could you share a few more details about your current setup?
These details will help narrow down whether this is a field mapping issue, permissions constraint, or something specific to how the cloning action is configured.
Thanks for your reply!
I attached two screenshots of the current automation rule. This rule works fine but doesn't clone the assignee to the cloned ticket. Because of that, the Audit Log looks fine and there aren't any errors.
I tried different solutions including a new automation rule which triggers if a new issue is created and sets the assignee for the KANBAN project. This rule never triggered. I also tried the trigger "work item updated" which also doesn't work.
Since the asignee in the original ticket is set correct i assume that the clone either doesn't receive the assignee before the ticket is cloned, or that the ticket is cloned already before it could fetch the assignee.
In the last screenshot you should see, that the "Assignee field" exists in the KANBAN space. It also exists in the main space.
We use JSM.
Kind regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Dominik Boehm Could you please confirm whether the assignee has access to the Jira product, especially if the target project is associated with Jira?
Additionally, ensure that the user has the “Assignable User” permission in the target project. You can verify this by navigating to the ⚙️ → System → Permission Helper.
In the Permission Helper:
This should help identify whether the issue is related to permissions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Akash Singh
Thanks for your reply!
I looked at the permission helper before and since i put myself in the test automation i had all the access.
Yesterday i worked on multiple workarounds. Right now if i manually change the field "Key-User aus Bereich" which is shown as "FI" in the screenshot to a different value i selected in the automation the assignee changes to myself as you can see in the second screenshot. But it still seems, that the cloning of the tickets causes the issue. I think the automation is cloning the ticket, but my second automation with the trigger "Issue created" doesn't trigger because it doesn't accept a clone as an created issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Dominik Boehm This does seem like unusual behavior, as I was able to set the Assignee using the same automation action successfully on my own site. I’d recommend checking the work item history as well to confirm there isn’t another automation rule, workflow post-function, or third-party app that may be clearing the Assignee field immediately after the work item is created.
Additionally, in your second automation rule that triggers on work item creation, make sure the following checkbox is enabled under the rule’s Flow details section. Since the work item is being created by another automation rule, this option is required for the second rule to execute correctly, as shown below.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.