> ## Knowledge Base Index
> Fetch the complete knowledge base index at: https://documentation.celestory.io/sitemap.xml
> Use this file to discover available pages before exploring further.
> Pure-Markdown content can be obtained by appending a '.md' suffix to the content URLs listed in the sitemap (without the trailing slash).

# Importing and Exporting a Module

# 📦 Importing and Exporting a Module

Beyond exporting your final application (already covered in the Export, Monetization category), Celestory lets you export **a single module or an isolated graph** to a file, to archive it or move it into another project. This guide describes what that file actually contains, how to import it elsewhere, and what happens on a naming conflict.

## 🚪 Where to Find It

Open the project menu, **Project** entry, then the **Import/Export modules** button at the bottom of the screen. A dedicated window opens, with a checkable tree (modules, each one's start graph, and any other graphs not attached to a module) and two buttons: **Import** and **Export**.

## 🗂️ What the Exported File Contains

The **Export** button produces a **ZIP** archive, named after the project and today's timestamp. Inside it:

- a **`data.json`** file describing everything you checked: the modules, the graphs and their blocks, the linked variables, each module's configuration, and the editor's version number at export time;
- a **`files/`** folder holding the binary files actually used by your selection (images, including a Chatbot module's character portraits).

🔺 So this is not just logic: the **referenced assets** (files used inside the blocks and inside the module's configuration) are genuinely included in the ZIP, not just their names. On the other hand, only what your selection **actually references** is carried over — nothing unused, and nothing belonging to an unchecked module.

Checking a module automatically checks its start graph and cascades to everything wired into it: variables, sub-graphs opened from a block, files in use. Checking a standalone graph (outside any module) works the other way: if it belongs to a module, that module gets checked along with it.

## 📥 Importing an Exported Module

In the same window, on the destination project, click **Import** and pick the ZIP file. The import:

1. creates a new file folder named `Import-<file name>` in your file library, so imported assets don't mix with the ones already there;
2. drops every binary file from the ZIP into it;
3. recreates the resources (graphs, blocks), variables and modules with **the same internal ids** they had at export time.

A success message confirms once the operation is done.

## 💥 Name Collision: the Silent Trap

🔺 If the destination project already has **a module with the exact same name** as the one you're importing, that specific module is **not imported** — it is simply skipped. No error is shown for this specific case: the success message still appears, as if everything went fine, even though one or more modules from your selection were silently dropped.

**What to do:** before importing, check that no module in the destination project already carries the exact name of one you're importing — rename one of the two beforehand if needed. After importing, count the modules you got to confirm they're all there.

Two rarer cases worth knowing about:
- If an imported **resource** already shares the same internal id as an existing one (typical case: re-importing the same file twice), the imported version **silently replaces** the existing one.
- **Variables**, on the other hand, are never deduplicated: re-importing the same file twice can create duplicates.

→ Next step: before an export meant to be re-imported elsewhere, rename your modules so they don't carry a generic name ("Module 1", "New module"…), which multiplies the risk of a silent collision on arrival.