SFDX Unlocked Packages Guide
  • Project Overview
  • Lifecycle Guidance
    • Development Models
    • Team Sprint Collaboration
    • Git Strategy
    • Development Guidance
    • Testing Guidance
    • Agile/DevOps shift-left testing
    • Code Promotion
  • Salesforce DX & CI/CD
    • Quality Hooks
  • Supporting Infrastructure & Environments
    • Environment Types
      • Scratch Org Guidance
      • Sandbox Guidance
      • Handling Secure Data
  • Opinionated Guide
    • Introduction
  • Developer Resources
    • SFDX Package Development
      • Introduction
      • Creating Unlocked Packages
        • Package Errors
      • Project Structure
    • Pipeline Introduction
    • Developer Machine Setup
      • VS Code Configuration
      • Creating the SFDX Project
    • Extras
      • SonarCloud / SonarLint
      • Code Review Checklist
      • Additional External Resources
    • Untitled
  • Running the Org
    • Team Responsibilites
    • Onboarding Resources
  • Journey to Unlocked Packages
    • Introduction
    • Getting Ready for Source Driven Development
    • Moving from Unmanaged to Unlocked
    • Unlocked Guidance
  • Test Automation
    • Manage Test Data
    • UI Test Automation - POM Framework
    • Agile/DevOps Shift-left Testing
    • Selenium Extent Reports - Dotnet Core
    • Dotnet Core Selenium Tests on Azure-devops-pipeline
Powered by GitBook
On this page
  • Introduction : Sandboxes and Scratch Orgs
  • Limitations
  • Role Assignments
  • Next Steps
  • Resources

Was this helpful?

Export as PDF
  1. Supporting Infrastructure & Environments

Environment Types

Introduction : Sandboxes and Scratch Orgs

Salesforce provides two types of non-production environments, Sandboxes and Scratch Orgs. Each fulfills a specific purpose and in the context of this guide will be used in the following manner:

  • Sandboxes

    • Limited use for fixed environments ( DEV INT, QA, UAT )

  • Scratch Orgs

    • Support all development / dev+test uses

Limitations

Each type of non-production environment has unique constraints which defines how these are used:

Sandboxes

Sandboxes are refreshed from the production environment, there are limitations on how frequently they can be refreshed, as well as how many can be created.

Scratch Orgs

Scratch Orgs only exist for limited time, can be easily created, but are completely empty when created, therefore any related data must be generated and scripted in.

Role Assignments

Development > Scratch Orgs

Assuming a Scrum/Agile approach, development efforts should be short lived, and involve a team including both developers and QA staff. Scratch Orgs marry well with the needs of these teams as it allows developers to work in an isolated environment, and leverage source control as a means of sharing changes with other team members. QA staff can validate changes being made as well as develop automated testing and related test data to exercise the functionality supported in a controlled manner.

Functional Validation > Sandboxes

Once a change is ready to be promoted, confidence that it will work in a production environment is often a requirement. Having an environment that closely mirrors production (including all related data) is important.

Next Steps

Resources

Official Salesforce Documentation

PreviousQuality HooksNextScratch Org Guidance

Last updated 6 years ago

Was this helpful?

Continue on to understand and how to structure these environments.

Code Promotion
Scratch Orgs
Sandboxes