Test before production
Validate against test sources, review a draft copy and prepare production access.
Use a dedicated test source to validate a new dashboard or workflow before connecting its effects to production. BytesMap can connect to an existing replica and create a reviewed dashboard draft with new connections. It does not provision database clones or activate production schedules as part of a copy.
Separate data and authority
Create separate source connections for test and production, each with its own credentials and limits. Keep test items in a clearly named project. Projects organize resources and can carry inherited grants, but they are not separate database tenants or a substitute for source-level permissions.
Use sanitized test records. Do not copy production secrets into query examples, notification bodies or test fixtures.
Validate the whole path
Exercise normal, empty, invalid and large results. Verify required inputs, filters, chart selections, nested Back navigation and refreshed deep links. Test the workflow's conditions with both matching and nonmatching data.
Route test effects to a test endpoint/channel. A preview can run real effects when you explicitly submit it; opening a preview does not create an isolated execution environment.
Move to production deliberately
Use Copy between projects to map a supported dashboard's dependencies to existing production connections. The compatibility review checks supported structured queries and explicitly captures bounded catalog metadata when needed. Native SQL and HTTP destination remapping remain blocked by this operation.
Review every source reference, saved query, destination input and published workflow revision. Data shapes and database dialects must match the intended source. Changing a project name does not rebind a query to another database.
The copy creates unpublished drafts. Review and publish its workflows, then publish the dashboard and verify with the intended reader/operator access. Configure production schedules separately. Start with conservative budgets and scheduling, then observe the actual source load.
Use replicas for the right workload
A read replica can isolate some reporting load from the primary, but replication lag and schema drift remain relevant. Ordinary reads route to the configured replica; writes remain on the primary. There is no silent read fallback when the replica is unavailable.
For immediate read-after-write behavior, use a source design that provides the consistency you need. Source safety documents the implemented routing and limits.