---
title: "Using internal IDs in JavaScript code or other scripts"
canonical: "https://support.appfire.com/space/PC/198017659/Using%20internal%20IDs%20in%20JavaScript%20code%20or%20other%20scripts"
format: markdown
---
> Macro (aura-html)

In many Jira instances, JavaScript code associated with field configurations or scripts in other languages—​ as those used with the ScriptRunner app —​ refers to configuration objects by their internal IDs. This may cause problems when trying to transfer a configuration from one instance to another.

For example, imagine you are working on your *DEV* instance. You create a new custom field called *Field One* of type multi-select. This new custom field is created with an ID of 10532. You then create a piece of Javascript code associated with a field’s description, so it refers to this new custom field by its ID, as in the following:

---

<sup> <script type="text/javascript" charset="utf-8" id="someId">
...
document.getElementById("summary").value = "URGENT REQUEST - " + document.getElementById("customfield_10532").value + " - " + document.getElementById("customfield_10143").value;
...
</script></sup>

---

Now that you have finished developing and testing everything in the DEV instance, you want to transfer all changes to *PROD*. You export the configuration, using Project Configurator, to an XML file, then import it into *PROD*. Everything goes correctly: a field called *Field One* of type multi-select is created in *PROD*, and the description with the script is also transferred to *PROD*.

## Problem

Project Configurator does not analyze and change arbitrary scripts that may be included in field descriptions, workflow extensions, etc. The script shown above is copied to *PROD* as it was in *DEV*. But when *Field One* is created in *PROD*, it is assigned a new ID by Jira that does not have to be the same as in *DEV: 10532*. In fact, it would be a very remarkable coincidence if they actually had the same ID.

This means the script in *PROD* will fail, as it references a custom field "customfield_10532" that does not exist. Even worse, the script might reference a completely different custom field and silently produce wrong results.

## Solution A

The best solution to this problem is referencing objects in scripts by name instead of using IDs. See our [How Project Configurator works](https://appfire.atlassian.net/wiki/pages/createpage.action?spaceKey=pc&title=How%20Project%20Configurator%20for%20Jira%20works&linkCreation=true&fromPageId=198017659) page for detailed information on the attributes Project Configurator uses to identify items. Those attributes are guaranteed to be preserved when the configuration is transferred to another instance.

## Solution B

If solution A is not practical in your case, the other strategy is looking for ways to make the IDs the same in *DEV* and *PROD*. You can achieve this if you perform changes following these steps:

1. Create all new items in *DEV* that will be required and may be referenced in scripts (for example, custom fields). Do not change scripts now.
2. Transfer these changes to *PROD* using Project Configurator.
3. Copy *PROD’s* database to DEV (for example, with an XML backup)
4. Edit the scripts as needed in *DEV*. Now that you have both in *DEV* and *PROD*, all items that will be referenced in scripts and they have the same ID.
5. Repeat step 2 and transfer the last set of changes to *PROD*.