# Import and Export Custom Field Definitions

Export a Custom Field definition when you want to reuse it on another FileWave Server or keep a portable copy. Importing restores the field definition, including its script and configuration, but does not make an untrusted script safe.

<p class="callout danger">**Review imported scripts before assignment.**  
Read the script, confirm the interpreter and permissions it expects, and test the Custom Field on a small device group before assigning it broadly.</p>

## Export Custom Field definitions

1. In FileWave Central, open **Assistants &gt; Custom Fields &gt; Edit Custom Fields**.
2. Select one or more custom fields
3. Select **Export**.
4. Save the "FileWave Custom Fields.customfields" file
5. Share online, or store for later

## Import Custom Field definitions

1. Download the custom field file
2. In FileWave Central, open **Assistants &gt; Custom Fields &gt; Edit Custom Fields**.
3. Select **Import**, then choose the `.customfields` file.
4. If the imported Custom Field contains a script, verify it is safe and appropriate for your environment.
5. Use **Edit Custom Field Associations** to assign the field to the required devices or groups.
6. You may also want to import custom field values

See [Custom Fields](https://kb.filewave.com/books/custom-fields/page/custom-fields "Custom Fields") for more on assigning fields to devices, and importing custom field values.

## Conflicts:

### Custom vs Internal

FileWave will let you re-use an internal name that is the same as another inventory element. If a Custom Field were added with an internal name of 'location', two 'location' internal names would co-exist the built-in internal name and the added Custom Field.

A prefix may be added to avoid confusion on matching inventory names. The prefix varies depending upon the method being used to reference the internal name.

<table id="bkmrk-method-prefix-exampl" style="width:100.357143%;"><tbody><tr style="background-color:rgb(251,238,184);"><td style="width:44.094302%;">Method</td><td style="width:17.049918%;">Prefix</td><td style="width:38.855781%;">Example</td></tr><tr><td style="width:44.094302%;">MDM Profile</td><td style="width:17.049918%;">custom\_field</td><td style="width:38.855781%;">%custom\_field.location%</td></tr><tr><td style="width:44.094302%;">Scripted (Launch Argument or Environment Variable)</td><td style="width:17.049918%;">CustomFields</td><td style="width:38.855781%;">%CustomFields.location%</td></tr></tbody></table>

### Custom vs Custom

If you are importing a custom field with an internal name that is the same as an existing custom field internal name you will see:

![custom field exists error.png](https://kb.filewave.com/uploads/images/gallery/2023-07/WFryKBn2v2Tya9Ij-custom-field-exists-error.png)

- **Cancel** - Stops the whole process and makes no changes
- **Skip** - If importing a custom fields file with multiple entries you can skip the one that is conflicting and continue
- **Keep both** - This will add \_2 to the internal name of the field you are importing
- **Overwrite existing** - Replace your existing entry entirely (as long as it isn't used in smart groups, inventory queries, etc)

<p class="callout warning">**Avoid overwriting until dependencies are reviewed.**  
Import the definition as an additional field when possible, compare both definitions, and resolve the conflict deliberately.</p>

If the internal names are in use (Smart Groups, Reports (formerly Queries), Automated Device Enrollment) when you press "**overwrite existing"** you will see this telling you where it is in use:

![internal_name-inuse.png](https://kb.filewave.com/uploads/images/gallery/2023-07/3D8GVS3GAO20YnjH-internal-name-inuse.png)