Production vs development sandboxes in Experience Platform

Why this matters

This matters because without development sandboxes, teams risk introducing errors into production environments. Testing schemas, mappings, and audiences in a live environment can lead to data corruption, broken profiles, or misaligned audiences—issues that impact campaign performance and user experience.

Development sandboxes provide a safe space to experiment without affecting real data or live operations. Without this isolation, mistakes in configuration could propagate across systems, causing costly delays or user confusion. The ability to move configurations between sandboxes ensures consistency and reduces manual errors. This structured approach protects production integrity and supports faster, more reliable deployment cycles.

The key ideas

A sandbox in Experience Platform is an isolated environment where teams can test changes without affecting live systems. Development sandboxes are used specifically to test schemas, mappings, and audiences before they are deployed to production. This means teams can experiment safely, try out new configurations, and fix errors without risking data or functionality in the live environment.

Each sandbox operates independently—data, schemas, and profiles in one sandbox are not visible or accessible in another. This isolation ensures that testing doesn’t interfere with production data or operations. Teams can use sandbox tooling to move configurations between environments, which saves time and reduces the risk of manual errors when setting up new features.

Development sandboxes are essential for building confidence before moving work into production. By testing in a safe space, teams can validate logic, check audience targeting, and ensure data flows correctly. This process supports accuracy, reduces errors, and helps maintain data integrity across the platform. Production remains unchanged and protected during this testing phase.

How to apply it

Teams begin by setting up a development sandbox within their Experience Platform organization. This environment allows them to test new schemas, data mappings, and audience definitions without impacting live data or production systems. Since sandboxes are isolated, changes in one do not affect another, ensuring safety during experimentation.

Once testing is complete and configurations are validated, teams use sandbox tooling to move those configurations—such as updated schemas or audience definitions—into a production sandbox for final review. This avoids the need to rebuild configurations manually, saving time and reducing the risk of errors. The production sandbox remains untouched until approved changes are ready to go live.

It’s important to note that development sandboxes are not meant for learning or simulation. AdsBot’s practice labs serve as independent training tools and are unrelated to Adobe Experience Platform sandboxes. Teams should rely on official AEP sandbox environments for real testing and configuration work.

Mistakes to avoid

• Avoid copying configurations directly from development to production without validation. Since sandboxes are isolated, data and schema changes in one do not propagate to another, but manual errors can still lead to misaligned logic or data mismatches. Always use sandbox tooling to move configurations, ensuring consistency and traceability.

• Never assume that a test in a development sandbox reflects production behavior. Differences in data volume, audience size, or system performance can cause discrepancies. Test thoroughly in development, validate with real-world scenarios, and confirm schema and mapping accuracy before moving to production. This prevents errors that could impact data integrity or user experience.

Quick checklist

• Confirm that the development sandbox is set up and accessible before starting any testing.
• Verify that all schema changes, mappings, or audience definitions are being tested in the development sandbox only.
• Ensure no production data or configurations are being accessed or modified in the development environment.
• Use sandbox tooling to copy and move configurations from development to production only when ready and approved.
• Double-check that the development sandbox is isolated from production so no datasets or profiles are visible across environments.
• Validate that all testing activities are complete and reviewed before any configuration is promoted to production.
• Avoid using AdsBot’s practice labs for actual Experience Platform sandbox testing, as they are independent simulations.