Migrating settings from Service Management to Jira Software

[Alexey]

I'm trying to automate issues in order to clone and link them from Service Management to Jira Software. But i'm getting errors. 

1. Unknown fields set during create, they may be unavailable for the project/type. Check your custom field configuration.

This one seems easy, i've created a complicated issue form with custom fields to collect necessary data from a customer. Now i need a way to copy/clone/include Jira Software projects into Service Management's Issue type schemes and Custom fields or re-create them and link in Jira. But:
When i'm trying to Settings > Issues > Issue type schemes > Associate there are only Service desk projects.
Same for Custom fields, no problem to add any field to Service projects (or Screens) and nothing even close in Jira Software.

2. Can not create issue in project/issue type10016/10035
This one probably will fix itself after first error.

 How to link multiply Service Desk projects into Jira Software to clone and link issues in both systems?

P.s. I know about marketplace apps, but they wont solve fields problem as at this moment Jira Service Desk got 71 fields and Jira software just "title" and "description" plus a couple more generic ones.

[Daniel Ebers]

Hi Alexey,

so far I understood the problem, I hope - but for the "Associate" step you need to associate a scheme, not a project (and there should not appear projects as you first need to select a project. Instead schemes should appear - possibly this is just the culprit)?

If not, could you please attach a screenshot for better understanding?

From reading your description you can associate schemes to a Jira Service Desk project - but not any other scheme to a Jira Software project.

Just in case here the documentation:
https://support.atlassian.com/jira-cloud-administration/docs/associate-issue-types-with-projects/

For cloning I saw a similar thread - there were some options that have been discussed.
The more basic linking (without clones) is documented here:
https://support.atlassian.com/jira-software-cloud/docs/link-an-issue/

Cheers,
Daniel

[Alexey]

Hey Daniel, thanks for the reply.

I followed the guide from your first link and at "How project administrators manage issue type schemes" Step 2. struggled to find Actions and Schemes. (see pic)

I collect data at Service Desk by using custom fields (see pic) and i need to pass collected data to my dev team in Jira.

[Daniel Ebers]

That was useful! It shows you are on a next-gen projects.

Configurations are per-project. Settings such as issue types and fields can't be copied over to other projects.

They are valid for one next-gen project.

I see two options:

1) you could create the very same configuration for the second project, also
2) you would need to go with a classic project - if this is possible you would need to evaluate, also along with team members

I am very sorry at this step, it is the nature how next-gen projects are built and you did nothing wrong as per configuration.

Here is some further reading if you want to gather the details:

Set up issue types in next-gen projects

• https://support.atlassian.com/jira-software-cloud/docs/set-up-issue-types-in-next-gen-projects/

Working with next-gen software projects

• https://confluence.atlassian.com/jirasoftwarecloud/working-with-agility-boards-945104895.html

[Alexey]

Ehh... so next-gen is just a very basic project tracking tool with minimum customization setting?

I thought 'next-gen' is something new, like new UI and classic will be obsolete after some time.

So in order to pass info from Jira Service Management tickets to Jira software i need:
1. create a classic project in Jira Software
2. create custom fields in Jira Software to receive data
3. with 3rd party software (like Exalate) or with build-in automation rules, connect both fields in order to link the cards AND duplicate the data to second card.

[Daniel Ebers]

The steps 1) - 3) are correct.

For the differentiation between next-gen and classic - both of them have their strengths. Some users say it is basic and restricted, yet - that is correct. On the other hand they are flexible and do not need Jira-admin interaction. Users have the maximum of freedom to do things.
On the other hand - classic projects have been around for a long time. They are proven and stable - the concept is well-known for a long time now.
I do not think that classic will go away (soon).