Hi everyone, I’m Marie and I’m a product manager on the Confluence Integrations team. We’re looking to get feedback from this group on improvements we have planned for the bulk issue creation experience from Confluence.

Sign up to speak with our team this week (Thur/Fri US timezone) here: https://calendly.com/ntollefson/confluence-usability-chat

Thanks!
Marie

I found this functionality recently but without the additional fields it's not worth using vs csv load. Would much prefer for users to be able to do this via Confluence but need additional fields. Thanks

Yes, this will be of great help and will save a lot of time and effort involved to create Jira issues. 

This will be of great help in scenarios where some fields are made mandatory.

This would greatly save the time and effort involved in creating Jira issues from Confluence, especially in the case of Business Requirements. Confluence makes it easier to read and ensures that all cases and scenarios are covered in the User Stories. If we are able to create Jira issues with other columns like labels and customized fields like FR ID, it would improve the traceability and save time as well as effort. Our company would greatly appreciate if we can get this feature soon.

Atlassian is a huge company with an enormous user tent.  I'm sure getting this macro to recognize any field that isn't a system field like summary and description, would be a fairly large undertaking.

That being said.....would be really cool if they could start with some "seemingly" easy fields like the shared teams field from advanced roadmaps.  Many boards are based off of the team field that this plugin brings.  Then maybe expand the macro field mappings from there?  

Pretty please......like with lots of sugar on top?

PS - I bet "Confluence Defense Squad" is a shared team within Atlassian   Wink wink.....

It would save at least 2 minutes per Jira created from confluence, considering we can do also bulk creation.
Time saving and productivity increase is a must for people using productivity and collaboration tools.

It would save sooo much time for us if this was done.

Hello,

we also request this feature! I am trying to create multiple Jira issues out of a Confluence document. For this I am selecting multiple rows of a table, right click, click "create Task", click on the "create multpile task" text and select the project as well as the other required fields. Thats okay and that works

The problem I (and everyone else here) got is, that I wanted to fill one or more custom fields I added as required to the "Task" issue of a specific project. In my case, I wanted to link the "Bereich"- row of my confluence table to the required "Bereich"- field of my issue.
I found a 2016 solution but it did not work since its outdated: https://confluence.atlassian.com/confkb/how-to-make-a-field-visible-in-the-create-jira-issue-dialogue-in-confluence-678560701.html

At the moment you can only do this manually and the effort involved is enormous, so please add this feature.

Created 8 years ago... 'Gathering Interest'..... they might as well rename that status to 'We Dont Care'....

Another vote for this, please let us add extra field mapping when creating tickets, at the moment the amount of work required to map fields makes using the feature as is almost worthless

Hello.

We'd also like to have this feature. Especially transferring estimations while creating the issues.
Currently when we create a bunch of issues we have to go and manually set the estimation for each.

As you can imagine this is tedious work especially for large projects.
I logged my initial support request in JST-650233 . For that request I have found a workaround but being able to automatically apply at least the estimate whilst creating multiple issues would be great.

Thanks.

@Emre Bodur
A bit unrelated to the current issue but I also use Tempo Timesheet in my cloud instance.

I'm not sure this applies to your workflow but I never have to edit my issues to link them to the right Tempo account.

After we create our Jira Software project, we set in "project settings -> Accounts" only one account and mark it "as default".

Every time someone logs times on an issue from that project, the right tempo is selected by default. My tempo reports are all good based on "account". I also show the "account" field on my time log view just in case.

Hope that helps.

We need in our company the "Account" field from Tempo, because this is a required field for our setup.

This will be very helpful for our teams, we can use this in Release Planning to quickly create Epics and Stories with the relevant information (Sprints, Versions, Teams etc.).

This would be super helpful to my team. Without this feature we have to use sheets -> zapier -> Jira to deploy issues with all the custom fields we need given x epic or y project. We keep these sheets in confluence as we want confluence to be the single repository of knowledge for us. Having this integration work robustly would streamline our entire process. Wish i could vote for this more than once! 

@Miguel - The work around I have found is to have a workflow with an additional state at the beginning, call it 'Pre-Populated' or something. You then create an automation rule to move tickets to To Do when all fields required are filled in.

So my action items get created from Confluence in the Pre-Populated state until they have a due date and assignee, then they automatically flip into the To Do state.

I then have two boards, one with Pre-Populated shown for my task creators, and one with Pre-Populated hidden for everyone else.

It's not a great solution but its the best i can find, as you can tell from my earlier comment I dont believe this will ever get done no matter how many people want it.

This is so necessary It cannot be overstated. We have a bunch of fields in our Jira tickets and as a result I can't use this feature. Ideally I should still be able to use this feature, even if the Jira ticket is created in an "unstable" state which then needs fixing. I want to go over the Confluence page, create the Jira issues I need, then go and find a list of those and "repair" them. That could be one by one or by a bulk edit. Either way I could get by. But the way things are right now, I can't use this feature at all, which waters down the value of the Confluence-Jira integration quite a lot if I'm frank.

I'm now watching this ticket as suggested by support while they were working JST-575924. I need to use the Story Points filed in the Confluence Jira Chart. Seeing that this issue is more than 6 years old, my confidence is not high, hopefully this is being taken seriously

These tickets are becoming a waste of time. It's just a way to distract us from the fact they will not bother to do what their customers need. I have given up hope.

We would really like: For n number of columns allow mapping of all system and custom fields

Also please consider this as the issue was reported in 2013! and we need this to encourage use of confluence and JIRA.

Has anyone else noticed the functionality to make multiple jiras from the table no longer works with the new editor?

We would really like it as well.

We handle the specification process in Confluence, and create a page per epic. On that page we create a table in which we add all the items needed for when the story is to be developed:

• Summary
• Description
• Internal notes
• Architectural notes
• Graphic design (images)
• Estimate

It would be soooo sweet if we could just select a table and all issues would be created in Jira.

Pretty please!

It's been about 6 years since this issue was raised and no progress is made. So I decided to unfollow this issue. The comment I made 5 years ago is still valid and covers the requests of all people (instead of I want "x field" "y field" to be included) so I am pasting it again below : 

—

I see a lot of requests for a lot of different fields (Assignee, title, description etc.) These fields can be mapped to table header fields names so that mapping can be handled automatically, i.e. If I have Assignee and Title headers in my table, they can be added to JIRA issue fields automatically. If I have Description field in my table that would be added automatically as well.

Lets have the fields from the table header map to JIRA fields automatically and everyone would be free to use their own method/logic in creating JIRA issues from tables

This would be extremely helpful for me and our team. We constantly have to make follow up items from meeting notes, and currently we have to create the issues in Jira instead of making them directly from Confluence - creating quite a bit of overhead. This feature would make me very happy!

This feature would be very appreciated to have! 

Ideally, we should be able to choose "add a field to map"and select whatever field we want. That way we can add any field we want after the "Summary, description and Epic link".

Story points and original estimate (Using Tempo Fields) would be a nice thing since we have some default "requirements" already containing user stories, descriptions, estimates, components, etc.

Might be repetitive relative to other comments, but I'm a strong advocate for adding this functionality.  In particular I want the ability to map at least the following fields from Confluence directly into the created Jira tickets:

• Epic Link (already works - thank you!)
• Summary (already works - thank you!)
• Description (already works - thank you!)
• Story Points
• Component (I'd be fine if this were limited to mapping to only one component)

Ideally there are two separate aspects linked to this feature requirement as below:

a) Ability to allow Jira Issue Creator (Cloud Version) to be configurable so that additional Jira fields can be mapped to the Table columns in confluence page where each row is picked up by batch process to create multiple tickets.

Following tickets need to be dealt separately as request features related to Jira issue creator:

• https://jira.atlassian.com/browse/CONFCLOUD-65526
• https://jira.atlassian.com/browse/CONFCLOUD-65513
• An definitely current Ticket to enhance the Jira issue creator

b) Ability to allow mapping of Confluence Page properties from the Properties section (if defined). This will help to populate common attributes from the confluence page against each Jira ticket created by Jira issue creator.

c) Ability to map the Confluence Page Labels to the Labels in Jira ticket would be great to extend the filteration.

It would be amazing if we can also create sub-tasks from tables

In requirements table would love to have component mapped to JIRA

When creating requirements, being able to map any table column to a standard Jira issue field would be a good start. Particularly being able to map a column to 'label', component and fix version.

I can also see the value in being able to map table columns to custom fields.

Very disappointed this is not provided out of the box, a bit incredulous, especially given how old this issue is.  Makes for an unnecessarily convoluted workflow when creating Jira issues from Confluence.

Need to add support for Acceptance Criteria field.

Due date would be great as well!

Definitely necessary. Every time I create these issues I always have to go into Jira anyway to change it.

Need Component, Affects Version, and custom fields.

We would love to add common fields like Estimate/Story points and Epic. 

I would say, at a minimum, in addition to the Summary and the Epic Link, I want Description and Verification Criteria (User Acceptance Criteria).  That way, I can define all these in Confluence then make the Issue in Jira with them all filled in already.

We very much need this as well. Mainly for Product Requirements. I'd like to:

• populate a custom field
• populate acceptance criteria
• combine two columns into my Jira Issue description (both my User Story and notes columns in my Confluence table)... in Confluence, these fields are better as different columns in a table but really should all be in the description field in Jira
• populate the component field (I'm okay with requiring the user to be smart enough for this to be a comma-separated list that will create a component if it doesn't already exist)

Yes! We would use this heavily!

We have two standard fields we would need to map, but I believe they are custom in our JIRA implementation: Size (small, medium, large), and Acceptance Criteria. We use this to build a statement for work for our clients, then just create those as linked JIRA stories when we start the work. We create the stories using the current functionality (title and description), then open each and manually add the two additional elements listed above.

Currently the ability to highlight text in a table and bulk-create JIRA issues is not particularly useful because of it's limitations.

Our product team writes product requirement documents which then need to be exported out to JIRA for our developers. All I need to be able to export is two columns of text, one which becomes the 'title' of the issue in JIRA, the other which becomes the 'description'. 

Then we just need it to copy over all formatting and also bring along any images which are embedded in those cells and attach them to the JIRA issue.

With this functionality it would become extremely useful. Currently I can export, but then I have to go into each one, fix up the description, fix the formatting, attach relevant images - which really makes the tool have no purpose as it doesn't save any time.

Also it's very good to access the components JIRA field FROM the JIRA project in Confluence page and able to choose/SET the applicable components values from Confluence in the requirement table against each requirement.

In case If this is too complex, not possible -  Would able implement custom fields (i,e simillar to Components JIRA system field - Select list multiple choice and other possible data types ) in general into Confluence helps to access and set the custom field values in the requiement table.

As each requirement has direct mapping with Components, it's good to do Mapping predefined fields like Description, Priority or Assignee, Components, IssueType as we will be having a option to create either EPIC or Story based on the requirement type we capture in the confluence page as part of the requirement table updated in it. 

Would be a great idea to just implement custom fields in general into Confluence. 

If fields could be added to pages and templates, if they could be editable by user or not, and editable from the page itself and not only from "edit" page,

1/ it would be much easier for user to modify a page,

2/ it'd be wonderful for admins who don't want users to be able to modify the entire page but only parts of it,

3/ it could lead to confluence reports and make it easier to link JIRA and other connectors like Salesforce.

Basically it would make Confluence much more than a documentation tool

Hope this will happen!

Can we have any progress on this?. Mapping predefined fields like Description, Priority or Assignee maybe a better start than waiting without anything like it is today.

I agree that this is critical functionality,and also agree that the simple ability to use the confluence headings to  map to efields like Project, Assignee, DueDate... would be all that is needed for an initial release of this feature. 

we really need a way to add the assignee when creating tickets from within Confluence

Yes, please make some progress on this.

I also support the call for taking over the  formatting from Confluence

It's hard to believe that this issue has been open for three years and there's still no action from Atlassian. The current functionality is pretty much useless. Why not at least add the ability to fill the essential fields: Project, IssueType, Summary, Description, and Assignee?

This is a critical missing component for us. As a first pass, just having JIRA fields Project, Issue Type, Summary, Description, Priority, Assignee would do the trick. Assignee is critical - we should be able to @mention a user in the Confluence table row and the resulting Jira ticket will have that user assigned.

Having the ability to create these tables in Confluence Page Templates with defaults including variable-ized @mentioning users (imagine a set of boilerplate tasks that always needs to be done...) would also be huge. 

Acceptance Criteria would help us dramatically

Is this issue already in roadmap ? When can we expect to see this in live ?

Thanks!