💬 In plain words: You can set up Salesforce Data 360 in three ways:
- Inside your existing org: Your CRM records flow straight into Data 360 with zero extra org management.
- In a dedicated standalone org: Keeps data strictly isolated and manages independent governance limits.
- In a sandbox: Lets you build, configure, and validate data pipelines before promoting them to production.
⚡ 1-Minute Summary
- Single-org setup: Attach Data 360 directly to your main production org for simple management and near-instant CRM connectivity.
- Enterprise multi-org setup: Use a dedicated Data 360 org with Data Spaces and Multi-Org Connectors to enforce regional compliance and neutral governance.
- DevOps lifecycle: Build and test configurations in a sandbox first, then package and deploy metadata cleanly to production using
Data Kits.
📌 Real-World Architecture Examples:
- Single-Brand Retailer: Operates one main Salesforce org. Attaching Data 360 directly minimizes administrative overhead and leverages native home-org connectors.
- Global Conglomerate (12 Business Units): Operates separate orgs across regions with strict data residency rules. A dedicated Data 360 org provides a centralized Center of Excellence (CoE) using
Data Spacesfor secure segmentation. - Development Lifecycle: Both companies use a Data 360 sandbox environment to build data models, streams, and Calculated Insights before deploying changes.
Core Architectural Concepts: The 3 Provisioning Models
Choosing where to provision Data 360 impacts long-term data governance, administrative effort, and architectural boundary management:
- Option A: Existing Production Org: Best for single-org or single-business-unit architectures. Data 360 shares the same security model, user licenses, sharing rules, and release schedule as your core CRM. It requires no additional Salesforce instance to maintain.
- Option B: Dedicated Standalone Data 360 Org: Ideal for complex enterprises with multiple Salesforce orgs, distinct brands, or varied business units. It acts as an unbiased data hub with independent administration, dedicated governor limits, and global schema standards.
- Option C: Sandbox Environments: Supported across Developer, Partial, and Full copy sandboxes. Teams can safely build data streams, map Data Model Objects (DMOs), and test identity resolution logic before deploying to production.
Architectural Decision Matrix
| Provisioning Option | Ideal Use Case | Architectural Trade-Offs |
|---|---|---|
| Existing Production Org | Single-org deployments and consolidated business units. | Simplest setup with lowest operational cost, but shares release cycles and org-level configuration limits. |
| Dedicated Standalone Org | Multi-org enterprises, holding companies, and centralized CoEs. | Independent governance and clean domain boundaries, but requires extra licensing, setup, and multi-org connector management. |
| Sandbox Environment | Development, testing, validation, and training. | Safe for prototyping, but holds only sample data. Requires Data Kits and metadata deployments to promote to production. |
🧠 Provisioning Rule: Single business → Existing Org (simplest, lowest maintenance). Multiple business units → Dedicated Org. Always build in a Sandbox first and promote via Data Kits.
⚠️ Scalability Trap: Even a Full-Copy sandbox holds only partial, sample Data 360 datasets. It is not an exact production replica. Do not run high-volume load, performance, or capacity sizing benchmarks inside a sandbox.
🧭 360 Card: Data 360 Provisioning Guidelines
- Core Rule: For one org, attach Data 360 directly. For multiple distributed business units, deploy a dedicated standalone instance.
- Key Benefit: Attaching to an existing org minimizes setup work and provides near-instant access to native Salesforce data.
- Operational Cost: A dedicated org requires its own admin oversight, user management, and integration pipelines across source systems.
- DevOps Strategy: Use
Data Kitsto bundle data streams, calculated insights, and DMO mappings into reusable packages for clean promotion across environments. - Volume Boundary: Dedicated orgs are designed for enterprise multi-org architectures, not single-brand operations.
Technical Deep Dive: Questions & Architecture Scenarios
Q: Should a single-org retailer and a 12-org global enterprise provision Data 360 the same way?
🎯 Core Rule: No. Single-org deployments should attach Data 360 directly to their primary CRM. Multi-org enterprises should evaluate a dedicated hub instance with multi-org connectors and Data Spaces.
Answer Breakdown:
- Single-Org Approach: Provision Data 360 within the existing production org. It automatically inherits the existing data model and security controls, avoiding unnecessary org maintenance.
- Multi-Org Conglomerate Approach: Deploy a dedicated Data 360 org. This establishes a central, neutral hub that standardizes data across all 12 source orgs without prioritizing any single team's existing schema.
- Trade-Offs: A dedicated org adds administrative overhead and requires multi-org connector configuration, but gives you clean governance isolation across business units.
Scenario: How can teams safely prototype and validate Data 360 pipelines without putting production data at risk?
Solution Architecture:
- Sandbox Enablement: Data 360 can be provisioned in sandboxes to build and validate data streams, DMO relationships, identity resolution rules, and segments end-to-end.
- Data Volume Constraints: Sandboxes contain only sample, representative data rather than full production volumes. Use them for structural and functional validation, not high-volume load testing.
- Deployment Best Practice: Package finished schema configurations into
Data Kits, and use standard Salesforce DevOps tools (Metadata API, Salesforce CLI, or Change Sets) to promote changes to production.