Import and Export
Import and Export lets you move your Global Configurator resources — connections, variables, datasets, files, and certificates — between environments without manual re-entry. Build and test your configuration in one environment, export it, and import it cleanly into the next.
What Can Be Moved?
Five resource types are supported. Each has its own export format designed to preserve the right content:
| Resource | Export Formats | Import Format | Notes |
|---|---|---|---|
| Connections | JSON, CSV | JSON | Password and secret fields stay encrypted |
| Global Variables | JSON, CSV | JSON | Encrypted variable values stay encrypted |
| Datasets | JSON, CSV | JSON | The active version of the dataset is exported |
| Files | ZIP | ZIP | Includes the actual file content plus metadata |
| Certificates | ZIP | ZIP | Includes the certificate file plus metadata |
Workflows and API Requests are not part of Import/Export. Only the five resource types in the table above are supported.
How It Works End to End
Export Options
Export All vs. Export Selected
When you export a resource type, you can choose:
- Export All — every record of that resource type is included in the export file.
- Export Selected — only the records you have checked in the table are included.
Use Export Selected when you want to promote only a specific subset of records (for example, only the connections belonging to one project) rather than everything.
Export Formats
| Resource | JSON | CSV | ZIP |
|---|---|---|---|
| Connections | Yes | Yes | No |
| Global Variables | Yes | Yes | No |
| Datasets | Yes | Yes | No |
| Files | No | No | Yes |
| Certificates | No | No | Yes |
JSON exports are human-readable and structured. They are the format used for re-importing.
CSV exports are useful for reviewing records in a spreadsheet. The column headers come from the display template for each resource type. CSV exports cannot be re-imported — they are for review purposes only.
ZIP exports (for Files and Certificates) bundle the actual binary content together with a metadata file (export_metadata.txt) that describes each record. This preserves everything needed to recreate the resource in another environment.
If your goal is to import records into another environment, always use the JSON or ZIP export. CSV is for human review, not for importing.
Import Behavior
Imports Always Create New Records
This is the most important thing to understand: importing never overwrites an existing record.
Every imported record gets a brand new ID assigned by the database. The original IDs from the source environment are discarded. This means:
- Running the same import twice will create two copies of each record.
- An import can never silently overwrite or damage an existing record in the target environment.
Name Conflict Resolution
If a record in the import file has the same name as a record that already exists in the target environment, the platform automatically renames the incoming record by appending a timestamp to its name.
Example: If Salesforce Production already exists, the imported record will be saved as Salesforce Production_20241115143022.
You can then rename it to something cleaner after import if needed.
File and Certificate Versioning on Import
When Files or Certificates are imported, their version history from the source environment is not carried over. Each imported file starts fresh:
- Total version count resets to
1.0 - The imported version is set as the active version
- The file content itself is re-uploaded to the target environment's storage (S3/MinIO for files, local storage for certificates)
Version history is environment-specific. Import gives you a clean starting point in the target environment, not a copy of the source environment's version history.
How Encrypted Data Is Handled
Some fields — such as connection passwords and encrypted global variable values — are stored in encrypted form. The export and import cycle respects this:
- On export: Encrypted fields are included in the export file as encrypted values. They are never written to the export in plain text.
- On import: The encrypted values are restored as-is — the encryption is preserved through the transfer.
- No plaintext exposure: At no point are secrets written unencrypted to disk or to the export file.
This means your credentials travel safely between environments, but it also means that if the encryption keys differ between environments (which is common in some setups), you may need to update credentials after import.
After importing connections into a new environment, verify that connection credentials are correct for that environment. A production connection may have different credentials than the QA version of the same connection.
Environment Promotion
The most common use of Import/Export is promoting configuration from one environment to the next as it gets reviewed and approved.
| Stage | What you do |
|---|---|
| Dev | Build and test connections, variables, datasets, files, and certificates |
| Dev to QA | Export approved records from Dev, import into QA for testing |
| QA to Staging | Export the QA-validated configuration, import into Staging |
| Staging to Prod | Export the approved configuration, import into Production |
Each promotion step creates fresh records in the target environment — nothing in the target is modified or deleted by the import.
Use Export Selected at each promotion stage to move only what has been reviewed and approved, rather than promoting everything at once.
What Import Does NOT Do
It is worth being clear about what import will never do:
- Import does not overwrite existing records. Every imported record is a new record with a new ID.
- Import does not delete existing records. Records in the target environment that are not in the import file are left completely untouched.
- Import does not modify records. If a record with the same name already exists, the imported record gets a new name — the existing record is never changed.
- Import does not expose secrets in plain text. Encrypted fields remain encrypted throughout.
- Import does not carry over file version history. Imported files start at version 1.0.
This makes import safe to run — you can always import without fear of damaging what is already in the target environment.
RBAC Permissions
Import and Export access is controlled separately for each resource type:
| Resource | Export Permission | Import Permission |
|---|---|---|
| Connections | GlobalConfigurator:Connection:export | GlobalConfigurator:Connection:import |
| Global Variables | GlobalConfigurator:GlobalVariable:export | GlobalConfigurator:GlobalVariable:import |
| Datasets | GlobalConfigurator:Dataset:export | GlobalConfigurator:Dataset:import |
| Files | GlobalConfigurator:File:export | GlobalConfigurator:File:import |
| Certificates | GlobalConfigurator:Certificate:export | GlobalConfigurator:Certificate:import |
Contact your platform administrator if you need export or import access for any of these resource types.
Tips and Common Questions
Run your import into a QA or staging environment before importing into production. Confirm the records look correct, then repeat the import in production with confidence.
Rather than exporting everything every time, export only the records that changed. This keeps your import files small and your target environment tidy.
Connection records are imported with their encrypted credentials from the source environment. Those credentials may not be valid in the target environment. Update them after import before using the connection in an automation.
After an import completes, the resource table in Global Configurator refreshes on its own. You do not need to reload the page — the imported records will appear in the list right away.