Import / Export

Overview

In Tray you can use Projects to manage a classic dev > production setup.

Tray has a system whereby you can export and import projects (and individual workflows) as json files.

This allows you to fully test your projects and workflows in a 'development' environment (i.e. using test/sandbox accounts and test data) before exporting to a json file, ready to be imported to your 'production' environment.

Exporting a project includes its workflows, project configuration, solutions, data tables, vector tables, APIM operations, and basic agent metadata. Only the structure/definition of these assets is exported - see What's included when assets move for exactly what does and doesn't travel with the project.

You can export and import between Orgs or workspaces within the same Org.

Please see the Setting up your environment and Understanding workspaces pages for further guidance.

Data tables, vector tables, APIM operations, and agent metadata are moved through the UI and the Tray Sync CLI. The public Projects and Solutions API endpoints do not move these asset types, so use the UI or CLI to promote projects that contain them.

What's included when assets move

When you export, import, version, or roll back a project, Tray moves the definition and structure of each supported asset - never its stored data or access-control configuration. Concretely:

Why data isn't moved: an exported project is a portable definition of how a project is built, not a copy of its runtime content. Stored data and access configuration are treated as environment-specific - you wouldn't want to overwrite your production data with data from your development environment, and the same applies to APIM policies and roles. After importing into a target environment, populate its data tables and vector tables and configure its APIM policies and roles in that environment.

Agents are a special case: because an agent is composed of multiple linked projects, only the agent's own basic metadata is included - its name, system prompt (instructions), and the tools and agent workflow it references. The relationships to its subprojects are not carried across, so a moved agent is not a fully functioning agent on its own until those subprojects exist in the target environment.

Archiving data tables and vector tables

An import never permanently deletes a data table or vector table. When the imported project no longer contains something that exists in the target - for example, because it was deleted in your development environment - Tray automatically archives it in the target instead of removing it: for data tables, the whole table or just the removed columns are archived; for vector tables, the whole table is archived (there is no per-column archiving).

Archiving is a soft delete that affects the asset's metadata only - the item is simply flagged as archived. The underlying data is never touched: a data table's rows stay in their real columns, so reads, writes, and any workflow references to an archived column keep hitting live data.

Archived items are hidden by default. Turn on the Show archived toggle in the data tables view to see them. From there you can unarchive an item to restore it, or delete it permanently yourself if the project genuinely no longer needs it.

Exporting and importing projects

Exporting a project

Projects are exported from the Project versions page, where you can export either:

• A saved project version (recommended for environment promotion). A version is a named, fixed snapshot, so you know exactly what you are exporting - and later, exactly what you imported. That gives you a reliable reference point: you can promote the same artifact through your environments and roll back to it if something goes wrong.
• The current project state, which captures the live project - including any unsaved changes - as an export. This is useful for comparing against a stable version, or for taking an ad-hoc external backup.

For environment promotion, prefer exporting a saved version. The "current" state is a moving target - it can include half-finished edits, and nothing records exactly what it contained at the moment you exported it, which makes an import hard to reproduce, review, or roll back. Saving a version first pins down precisely what you are promoting. See Project versioning for how versions work.

Exporting produces a json file that you can then import into another project or workspace. You would normally export from a 'dev' workspace and import to a 'prod' workspace.

Importing a project

How you import depends on whether the target project already exists:

• Into an existing project - open the Project versions page and select Import project version in the top-right corner.
• As a brand new project - select + Add project, then choose Import project and follow the steps (upload the json file, resolve dependencies, and so on).

Exporting and importing workflows

You can also export and import individual workflows. Treat this as moving a standalone change rather than promoting between environments - for environment promotion, work at the project level so that references to configuration and other assets stay intact and are mapped correctly.

Importing a workflow into a project

• As a new workflow - use the + Add workflow button in the workflow list, or the + button in the project sidebar.
• Overwriting an existing workflow - open the workflow in the builder, then use the three-dot menu in the top-right of the builder header (alongside the workflow title) and choose Import workflow. The import overwrites the current workflow.

Exporting a workflow

From the same three-dot menu in the workflow builder header, choose Export workflow to save the workflow as a json file.