nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Cloud Automation: Auto-populate fields from a Master Project issue based on Asset ID

PLaksh11

Hi Community,

I'm looking for the best approach to implement the following requirement in Jira Cloud.

Setup

I have a Master Project that contains around 100 issues. Each issue represents an asset/application record and contains:

Asset ID (Custom Field)
Application Name (Custom Field)
Environment (Custom Field)
Support Group (Custom Field)

Example:

Master Project Issue

Asset ID: 100

Application: Payment App

Environment: PROD

Support Group: L2 Team

Requirement

In another project, users create issues using the same set of custom fields.

When a user enters: Asset ID = 100 and click on create button.

I want Jira to automatically:

Find the matching issue in the Master Project.
Retrieve the values of all other custom fields.
Populate those fields in the newly created issue.

Note: when user enter Asset ID in create screen, and as soon as click create button then automation rule should find the Asset ID number which matches to other project issue and auto update the below fields after ticket creation.

Application Name (Custom Field)
Environment (Custom Field)
Support Group (Custom Field)

Thanks,

Prathap DL

Accepted answers

Cristian Quiroz

Hi @PLaksh11

You can achieve this with a Jira Automation rule using the following setup:

Rule Configuration

1. Trigger: Issue Created

Scope it to your target project (not the Master Project)

2. Condition: Issue fields condition

Check that Asset ID is not empty (to avoid running on issues without it)

3. Action: Lookup Issues

JQL: project = "Master Project" AND "Asset ID" = "{{issue.Asset ID}}"
Replace "Asset ID" with the actual custom field name or ID (e.g., cf[XXXXX])
This will find the matching issue in your Master Project

4. Action: Edit Issue (current issue)

Application Name → {{lookupIssues.first.Application Name}}
Environment → {{lookupIssues.first.Environment}}
Support Group → {{lookupIssues.first.Support Group}}

Notes

Use {{lookupIssues.first.fieldName}} since you expect only one match per Asset ID
If your custom field names have spaces or special characters, use the field ID instead: {{lookupIssues.first.customfield_XXXXX}}
Make sure the custom fields exist in both projects and are on the respective screens
The Lookup Issues action has a 100-issue limit, but since you're matching a single Asset ID this shouldn't be an issue

Summary Flow

Trigger: Issue Created (Target Project)
  → Condition: Asset ID is not empty
    → Lookup Issues: find match in Master Project by Asset ID
      → Edit Issue: copy Application Name, Environment, Support Group from lookup result

Hope this helps! 👍

All comments

Cristian Quiroz

Hi @PLaksh11

You can achieve this with a Jira Automation rule using the following setup:

Rule Configuration

1. Trigger: Issue Created

Scope it to your target project (not the Master Project)

2. Condition: Issue fields condition

Check that Asset ID is not empty (to avoid running on issues without it)

3. Action: Lookup Issues

JQL: project = "Master Project" AND "Asset ID" = "{{issue.Asset ID}}"
Replace "Asset ID" with the actual custom field name or ID (e.g., cf[XXXXX])
This will find the matching issue in your Master Project

4. Action: Edit Issue (current issue)

Application Name → {{lookupIssues.first.Application Name}}
Environment → {{lookupIssues.first.Environment}}
Support Group → {{lookupIssues.first.Support Group}}

Notes

Use {{lookupIssues.first.fieldName}} since you expect only one match per Asset ID
If your custom field names have spaces or special characters, use the field ID instead: {{lookupIssues.first.customfield_XXXXX}}
Make sure the custom fields exist in both projects and are on the respective screens
The Lookup Issues action has a 100-issue limit, but since you're matching a single Asset ID this shouldn't be an issue

Summary Flow

Trigger: Issue Created (Target Project)
  → Condition: Asset ID is not empty
    → Lookup Issues: find match in Master Project by Asset ID
      → Edit Issue: copy Application Name, Environment, Support Group from lookup result

Hope this helps! 👍

Marc -Devoteam-

Hi @PLaksh11

You can do this by automation as suggested by @Cristian Quiroz

But why don't you use assets for this, then there is no need for automation, this is a way more stable setup.

You can create a assets custom field where a user can directly select the right application and in the field configuration of the asset field, you can show al details of the Asset Object.

So my suggestion and best practice is to use Assets for this.

PLaksh11

Hi @Cristian Quiroz i tried this for summary field to check first. and its not working and showing error in audit log.

Screenshot 2026-08-14 214721.png Screenshot 2026-08-14 214833.png

Thanks,

Prathap DL

Cristian Quiroz

Hi @PLaksh11 ! I found the issue, look at your resolved JQL in the audit log:

(project = project in (14535) AND Summary = "test87490") AND (project in (17367))

There are two problems here:

JQL syntax: project = project in (14535) is invalid. Use project = "14535" or project in (14535)
Scope conflict: Your automation rule scope is set to project 17367 only. Jira appends AND (project in (17367)) to the Lookup JQL — this contradicts your project in (14535) condition. An issue can't be in both projects, so the lookup will always return zero results.

Fix: Edit your automation rule scope to include both projects (the trigger project AND the Master Project where you're looking up issues). Or set the rule scope to Global so the Lookup can search across projects without restrictions.

Andrey - Guenov Labs

Cristian's diagnosis of the scope conflict is the main thing — your rule scope was limited to one project, so Jira appended AND (project in (17367)) and the lookup could never match. A few things that will bite you next, once the scope is fixed:

1. Reference the custom field by ID, not display name. In the Lookup Issues JQL, {{issue.Asset ID}} won't resolve reliably when the field name contains a space. Use the smart value form with the field ID instead:

project = MASTER AND cf[XXXXX] = {{triggerIssue.customfield_XXXXX}}

You can find the ID under Settings → Issues → Custom fields → ⋯ → Edit details (it's in the URL as customfield_XXXXX).

2. Quote text values, don't quote numbers. If Asset ID is a text field, you need = "{{triggerIssue.customfield_XXXXX}}". If it's a number field, quoting it will make the JQL fail. This catches a lot of people.

3. Use {{triggerIssue.…}} rather than {{issue.…}} inside a lookup. After a Lookup Issues action, {{issue}}context can shift depending on where you reference it. {{triggerIssue}} is unambiguous.

4. Add a guard so failures are visible. Between the lookup and the edit, add an Advanced compare condition: first value {{lookupIssues.size}}, condition "greater than", second value 0. Otherwise a zero-result lookup silently writes empty values over the fields and looks like the rule "did nothing."

5. On the Assets suggestion — Marc is right that it's the more stable long-term model, and if it's available to you I'd take it. Just be aware Assets is a Jira Service Management Premium/Enterprise capability, not something you get with Jira Premium alone. If JSM isn't in your licensing, the automation approach above is the pragmatic path and there's nothing wrong with it at 100 records; the thing to watch is that a rename in the master project won't propagate to already-created issues, so if that matters, add a scheduled rule to re-sync.

Marcelo Montaño Sánchez

Hi @PLaksh11

I have used a similar approach before, and I think Automation is a good fit for this requirement, as long as the master data remains relatively simple.

There are a few things I would consider before implementing it:

Make sure the Asset ID is unique in the Master Project.
Keep the master issue focused on a relatively small and stable set of fields.
Consider the Automation lookup and execution limits if the solution grows significantly.
Most importantly, define what should happen when the master issue is updated after the target issue has already been created.

That last point can be particularly important for historical or audit purposes. If the fields are copied only at creation time, the target issue becomes a snapshot of the master data. If the master record changes later, should existing issues also be updated, or should they retain the values that were correct when the request was created? Automatically synchronizing them later could potentially change information that was historically accurate.

I used to manage similar information through a Master Project before having Assets available in my instance. It worked well for relatively simple data.

However, if the information becomes more complex, requires relationships with other entities, or starts behaving more like a database of assets than actual work items, Assets would be a better fit and easier to maintain in the long term.