---
sourceDocument: Brazil Workflow Data Fabric
sourceDocumentLink: https://www.servicenow.com/docs/r/integrate-applications

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Workflow Data Fabric

ft:clusterId :

    - crint

bundleId :

    - crint

workflow :

    - Creator


---

# XML records from lists

# XML records from lists {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
You can directly export records as XML from any list or form.  
This export process preserves all record field values including system generated field values such as:

* Sys ID
* Creation date
* Update date
{#c_XMLRecordsFromLists__ul_cqv_zdk_3s}  
The XML import process directly inserts records into the target table. During the import the system:

* Ignores any business rules that normally apply to the table.
* Does not provide any opportunity to transform incoming data.
* Automatically matches a reference field's display value to the local Sys ID for some tables.
{#c_XMLRecordsFromLists__ul_pqv_zdk_3s}

This process is good for directly copying records from one system to another but does not
remove the need to know the relationships between tables. If you need validate or transform data
or reconcile the sys ID values of reference fields, use an XML import set instead.

## Automatic matching of display values {#ariaid-title2}

During the import of XML records, the system attempts to match some reference field
display values to a local sys_id value.

If the system finds an existing record with a matching display value on the local instance, the
import uses the sys_id of the existing record rather than the sys_id of the imported
record.

For example, suppose you export an incident record that is assigned to the user John Smith. In
the exported XML file there is an entry such as:

    <incident>
    	...
    	<assigned_to display_value="John Smith">7712173d2ba80200c5244f74b4da159a</assigned_to>
    	...
    </incident>

This user already exists on the target instance but has a different sys_id value such as:

    <sys_user><name>John Smith</name>
    	...
    	<sys_id>18cab8de2be80200c5244f74b4da15f7</sys_id>
    	...
    </sys_user>

Since the display value matches an existing record, the system uses the local instance's
existing sys_id value for the reference field such as:

    <incident>
    	...
    	<assigned_to display_value="John Smith">18cab8de2be80200c5244f74b4da15f7</assigned_to>
    	...
    </incident>

The system can match display values for the following tables.

* User \[sys_user\]
* Group \[sys_user_group\]
* Role \[sys_user_role\]
* Group Roles \[sys_group_has_role\]
{#c_AutomaticMatchingOfDisplayValues__ul_ks1_gfk_3s}