Copy between projects

Copy a tested dashboard into another project with explicitly chosen connections. BytesMap reviews its dependencies and creates a new unpublished draft, including the captured views, queries and workflows. The original dashboard stays in place.

This is useful for moving a supported dashboard from test sources to production sources, or reusing it against another database with a compatible schema. It does not clone a database or transfer customer records.

Prepare the destinationCopy Anchor Link

Create the destination project and connect its sources first. Both projects must belong to the same organization on the same BytesMap instance. A database can be remote; copying between remote BytesMap metadata projects is not supported.

You need dashboard administration, destination-project write access and the current permissions required by its dependencies. Project-scoped access must also allow the operation. A copy does not transfer source credentials, grants or publisher authority. Set up destination event datasets and verified notification channels when the dashboard's workflows use them.

Review and copyCopy Anchor Link

1. Open the dashboard's context menu and select Copy with new connections.
2. Choose an existing destination project, then select Review connections. This discovers saved dependencies without reading application data or opening database connections.
3. Choose a destination for every listed source, event dataset and notification channel. Review the names carefully, especially when test and production connections have similar names.
4. Select Check compatibility. BytesMap first checks the mappings and known portability blockers. If catalog evidence is missing or stale and no other blocker prevents copying, it reads the required database catalogs and reviews again. Fresh evidence is reused.
5. Read the findings. Resolve blockers before continuing. When the review is ready, select Create draft copy, then Open draft.

The new draft retains shared dependencies and supported nested navigation. Copying does not publish it, run a query or workflow, activate a schedule, or write application records. Review copied workflows and publish them before publishing the dashboard when its publication checks require them. Scheduling remains a separate setup step.

Understand the compatibility checkCopy Anchor Link

Catalog capture supports PostgreSQL, MySQL and MariaDB. It reads metadata such as table names, column types and constraints, with time and result limits. It does not sample customer records. Read evidence uses the configured read replica; write-target evidence uses the primary. There is no silent fallback from a failed replica to the primary.

Evidence is tied to the connection and read/write purpose, and expires after fifteen minutes. A connection change or stale dashboard revision requires a new review. The dialog retains applicable mapping choices when refreshing that review.

For supported structured queries, the review checks referenced tables and columns. Write targets also check known restrictions such as required columns, enum values, primary keys, and changed unique or foreign-key constraints. A successful review means the graph is ready for a draft copy. It does not prove query speed, data correctness or every write constraint. CHECK constraints, triggers, row-level policies, defaults, generated expressions and some index semantics still require your validation. A database schema can also change after review.

Use source safety and query cost to prepare the copied dashboard for its actual workload. Validate its inputs, filters, drilldowns and intended reader permissions before publication.

Cases that need more workCopy Anchor Link

The review blocks cases it cannot safely rewrite or validate:

• Native SQL and custom flow steps. Matching database types alone does not establish query compatibility.
• HTTP workflow destinations and authentication remapping, including dynamic URLs. Mapping only an origin is insufficient.
• Destinations in other dashboards, conflicting pinned definitions, or parameter-picker views that are not already captured in the dependency graph.
• Environment-backed or managed credential references without a stable, versioned identity for review.

These limits do not prevent those features from being used in their existing dashboards. They limit this copy operation. Database clone provisioning, cross-organization copying and schedule migration are not included.

Recover an interrupted copyCopy Anchor Link

If the response is interrupted, the draft may already exist. Use Retry copy to retry the same request instead of starting another copy. The backend returns the same result for that request after checking current access.

Closing and reopening the dialog, or navigating away and back within the same workspace session, retains the pending attempt. A failed retry retains it too. This recovery is held in memory: a full page reload or browser restart clears it. After a reload, inspect the destination project's drafts before starting another copy.

Use the SDK or an agentCopy Anchor Link

The same operations are available through the SDK, HTTP and MCP: workspaces.promotionReview, sources.capturePromotionSchema and workspaces.promotionApply. Capture must be explicitly requested; review does not run it automatically. Apply requires the reviewed fingerprint and a request key. Keep the exact key and body on an uncertain retry.

See the workspace operation reference, source operation reference and MCP guide for the current contracts and permissions.