Automation: Unable to add parent or epic to created issue

Question

I'm experiencing what appears to be a regression with the new Create work item automation action after the Epic Link → Parent migration. My use case I have a scheduled Automation rule that creates multiple Task work items. Each Task should be created under a specific, existing Epic (for example, GMR-155). This automation worked before July. The issues only started after the recent Epic Link → Parent changes in Jira Cloud. What I'm seeing When configuring the Create work item action: * The Parent field does not allow me to select an issue like the Epic field. (Epic field is now blocking automated tickets from being created.) * Instead, the Parent field only allows selecting:* Work item * Trigger work item * I've also tested using the Parent Field by simply typing in GMR-155, and that did not work. Because this is a Scheduled rule, there is no trigger work item, so neither option is usable. Additional testing I've tried several approaches: * Creating the Task without a Parent → Works successfully * Setting the Parent field → Fails * Using the legacy Epic Link field instead → Also fails * Adding a branch to edit the created Work Item to add the Epic or Parent. → Both options fail. * Using Additional Fields JSON: { "fields": { "parent": { "key": "GMR-155" } } } → Also fails. The Epic exists, is in the same project, and the created issue type is a standard Task, so the hierarchy is valid (Epic → Task). I've also recreated the Create work item action from scratch to rule out a corrupted automation configuration, but the behavior is the same. Why I think this may be a regression From what I can tell: * Removing Parent/Epic Link allows the automation to complete successfully. * Adding either Parent or Epic Link causes the Create action to fail. * The Parent UI no longer behaves like the previous Epic picker and appears to only support automation-context work items. Questions * Is anyone else seeing this behavior with the new Create work item action? * Has the expected configuration changed following the Epic Link → Parent migration? I found this previous Community thread, but the accepted solution does not appear to resolve the issue anymore in my Jira Cloud instance, so I'm wondering if there has been a recent regression or behavior change since that discussion. https://community.atlassian.com/forums/Jira-questions/Automation-Unable-to-add-Parent-to-created-issue/qaq-p/3017814

Sami Shaik · Answer

Hi @Ashley_Lange  , good news: I rebuilt your exact scenario in a sandbox today (Scheduled trigger, Create work item, Task under a specific Epic) and it works. The Parent field can do this, but its dropdown hides it, which is almost certainly what you are hitting.

The trap: the Parent dropdown only shows "Work item / Trigger work item" until you type. Those two options are all it offers at rest, which makes it look like a specific Epic cannot be selected on a scheduled rule. But the field is a type-ahead: type your Epic's key directly into the box and the actual Epic appears as an option.

The tested steps:

* In the Create work item action, set Space/Project explicitly (do not use "Same space" on a scheduled rule: with no trigger work item there is no context to inherit, and the run fails with "The project or issue type wasn't set")
* Set the work type explicitly (Task)
* Add the Parent field, ignore the two default options, and type the Epic key (for example PROJ-12) into the box, then select the Epic when it appears
* Save and run: in my test the Task was created directly under the Epic, confirmed in the work item's breadcrumb

No JSON needed once the picker path works. Verified in-product today on a Cloud instance; if typing the key still finds nothing on your site, reply here with what the box shows and we can dig further.

Andrea Robbins · Answer

If the trigger is upon issue creation, you have to ensure any fields you want to set is on the create screen - put it on the edit screen as well while you're at it.

See if this fixes it. I don't remember having issues with this in the past, but it has been a while.