Sandbox and Deployment

What is Sandbox? 

Salesforce sandbox (Test environment) enable us to test new configuration, code and automation outside of your production (live) instance. 

Salesforce Deployment Procedures Overview | Peeklogic

A Salesforce Sandbox environment is a testing and development environment that allows users to safely build, test, and experiment with Salesforce 

configurations, code, and customizations without affecting the live Production environment. 

Itʼs a replica of your Production org with some or all of your metadata and data depending on your sandbox . 

Metadata* Metadata describes the structure and configuration of objects, including their fields, types, relationships, permissions, and properties in 

Salesforce. 

Data ⟶ Data refers to the actual records stored within Salesforce objects, representing business information like customer details, sales data, or 

interactions. 

Plan——>Build—>Test—>Deploy—>Release 

Use Cases: 

Development: Build and test applications and automations. 

Testing: Perform unit, integration, and User Acceptance Testing (UAT). 

Training: Provide a safe environment for employee training. 

Data Migration: Test data imports and integrations before applying them to production. 

Types of Environment 

Production Live(login.salesforce.com) 

Development and Testing →test.salesforce.com-sandbox 

 Types of Sandboxes: 

Developer Sandbox: A basic sandbox for development and testing with minimal data (metadata only). 200 MB 

Developer Pro Sandbox: Similar to Developer Sandbox but with increased storage for data. 

Partial Copy Sandbox: Includes metadata and a subset of data (via a sandbox template). 

Full Sandbox: A complete replica of the production environment, including metadata and all data. 

Refreshing Sandbox (copying production metadata into sandbox) 

Refreshing a sandbox means copying the current production metadata and, optionally, data into the sandbox for testing or development purposes.

Making it replica of the production environment The org ID of the sandbox changed each time. 

Sandboxes must be refreshed to update them with the latest production data and metadata. 

Refresh frequency depends on the sandbox type: Developer Sandbox: Once per day. 

Developer Pro: Once per day. Partial Copy: Every 5 days. 

Full Sandbox: Every 29 days. 

 Advantages: 

Prevents production issues by allowing thorough testing. 

Speeds up development by providing a separate environment for developers. 

Maintains data security by isolating test activities.

What is a Partial Copy Sandbox? 

Partial copy Sandbox include below components from production Configuration 

Metadata Apex class users 

Records (Sample of selected object) 

Configuration: 

All configuration settings from production, such as: Workflow rules. 

Validation rules. 

Object schemas (Custom Objects, Fields, Relationships). Page layouts and profiles. 

Metadata: 

All metadata from production is included: 

Apex Classes, Triggers, and Visualforce Pages. Lightning Components. 

Custom Settings. 

Reports and Dashboards. 

Apex Classes: 

All Apex code is copied. 

  Useful for testing code changes in a realistic environment. 

Users: 

Includes all user records from production. 

User records are copied without their passwords (users need to reset passwords in the sandbox to log in). 

Records (Sample of Selected Objects): 

  A subset of data defined by a Sandbox Template is copied. 

Example: You can specify copying 10,000 records for the Account object or only specific opportunities related to active deals. 

Relationships between records are maintained for objects included in the template. 

Note: You can not see NEXT button under partial copy sandbox creation unless we donʼt have one sandbox template .

What is Deployment Setting? 

After Development completed we will be moving the changing from one environment to another environment 

In Salesforce, 

Deployment Settings determine how changes or components from one Salesforce org can be deployed to another org. 

Types of Connection 

Allow Inbound Changesand Accept Outbound Changes, which are concepts related to Change Sets in Salesforce Deployment Connections. 

  1. Allow Inbound Changes 

Refers to enabling a sandbox or production org to receive change sets from another org. 

You must configure deployment settings to allow specific orgs to send changes (e.g., from Sandbox to Production). 

Typically managed via Deployment Connections in Salesforce Setup 

For example: Below sandbox shows that QA sandbox receive changes from developer sandbox 

  1. Accept Outbound Changes 

Refers to a sandbox or org that sends change sets to another connected org. 

The org sending changes must have a valid deployment connection to the receiving org. 

Use Case: 

For example: The below UAT sandbox will receive change from from QA sandbox

Leave a Comment

Your email address will not be published. Required fields are marked *