App Deployment

Sandboxes are copies of the production environment used for development, testing, and training without affecting real data.

The 4 Sandbox types:

Type	What it copies	Storage	Refresh	Main use case
Developer	Metadata only (configuration)	200 MB	1 day	Individual development
Developer Pro	Metadata only (more storage)	1 GB	1 day	Team development or unit testing
Partial Copy	Metadata + template-selected data	5 GB	5 days	Testing with partial real data
Full	EVERYTHING: metadata + all data + files	Same as production	29 days	UAT, performance testing, staging

Important details per type:

Developer Sandbox:
- The lightest and fastest to create.
- Only copies configuration (objects, fields, flows, page layouts, etc.).
- Does NOT copy any data (records).
- Ideal for isolated individual development.

Developer Pro Sandbox:
- Similar to Developer but with more storage (1 GB vs 200 MB).
- Ideal when multiple developers work on the same project.
- Also doesn't copy data.

Partial Copy Sandbox:
- Copies metadata + a data subset defined by a Sandbox Template.
- The template defines which objects to include and how many records per object.
- Ideal for testing with real data without copying EVERYTHING.
- Maximum 5 GB of data.

Full Sandbox:
- Copies ABSOLUTELY EVERYTHING: metadata, data, file attachments.
- Can take hours or days to create depending on volume.
- Minimum refresh: 29 days between updates.
- Used for: UAT (User Acceptance Testing), performance testing, pre-production staging, training with real data.
- Most expensive in terms of licensing.

Recommended development lifecycle:

Developer Sandbox → Developer Pro → Partial Copy → Full → Production
   (Development)    (Integration)    (QA/Testing)   (UAT)  (Live)

Sandbox Refresh:
- Refreshing a sandbox completely replaces it with a new production copy.
- All unmigrated changes are lost.
- Refresh intervals are minimums, not fixed — you can wait longer but not less.

Sandbox Login:
- Different URL: https://test.salesforce.com (not login.salesforce.com).
- Username: user@company.com.sandboxname.
- When creating a sandbox, only users with active permission are copied (with passwords reset).

Change Sets are Salesforce's native tool for migrating metadata (configurations) between connected environments.

Fundamental concepts:

Outbound Change Set:
- Created in the SOURCE environment (e.g., Developer Sandbox).
- Components to migrate are selected (objects, fields, flows, page layouts, profiles, etc.).
- Uploaded to the target environment.
- The Add Dependencies button automatically analyzes what additional components your selection needs.

Inbound Change Set:
- Appears in the TARGET environment after upload.
- An administrator must manually Deploy the Change Set.
- Before deploying, can run Validate to verify no errors without making actual changes.
- Deploy can include: Run default tests, Run specified tests, Run local tests, Run all tests.

Critical Change Set rules (asked on the exam):
1. Only work between connected environments (sandboxes from the same production org).
2. They are unidirectional — sent from source, received at target.
3. Only migrate metadata, NEVER data (records).
4. Do NOT migrate: Custom Settings data, users, record data, complete profiles (only specific profile changes are migrated).
5. Components are overwritten in the target (not merged).
6. Destructive changes (deleting components) CANNOT be done with Change Sets.

Connection Settings:
Before using Change Sets, environments must be connected. Configured in: Setup > Deploy > Deployment Settings. Each environment must explicitly allow receiving Change Sets from other environments.

What components can be included in a Change Set?
- Custom Objects, Custom Fields, Page Layouts, Record Types.
- Flows, Validation Rules, Formula Fields.
- Profiles (partial: only permissions for included components), Permission Sets.
- Lightning Pages, Quick Actions, Custom Buttons.
- Apex Classes, Apex Triggers, Visualforce Pages, LWC.
- Reports, Dashboards, Email Templates.
- Custom Metadata Type Records (yes, they migrate!).

Other deployment tools:

Tool	Type	Main use
Change Sets	Declarative (UI)	Simple migrations between connected sandboxes
Salesforce CLI (sf/sfdx)	Command line	Modern development, CI/CD, Scratch Orgs
Metadata API	Programmatic API	Deployment automation, third-party tools
Packages (Managed/Unmanaged)	Packaged	Solution distribution
VS Code + Salesforce Extensions	IDE	Development with metadata retrieval and deployment

Salesforce CLI and Salesforce DX:
- Modern development approach based on source control (Git).
- Uses Scratch Orgs (temporary environments) instead of Developer Sandboxes.
- Enables CI/CD pipelines (continuous integration / continuous deployment).
- Not deeply required for the PAB exam, but you should know it exists.

Packages are containers of Salesforce components that can be distributed and installed in other organizations.

Unmanaged Packages:
- Components are installed as independent copies in the target org.
- Once installed, they can be freely modified (editable).
- Do NOT support upgrades — no way to update already installed components.
- The creator loses control over components after installation.
- Ideal for: configuration templates, starter kits, metadata transfer between unconnected orgs.

Managed Packages:
- Components are protected (obfuscated Apex code, locked components).
- The creator (ISV) maintains control and intellectual property.
- Support upgrades: Updates can be sent to installed orgs.
- Can be published on AppExchange after passing Security Review.
- Installed components CANNOT be modified by the user (except exposed configurations). They have a unique namespace prefix.
- Ideal for: ISVs (Independent Software Vendors), commercial app distribution.

Comparison table:

Feature	Unmanaged	Managed
Editable components	✅ Yes (after install)	❌ No (protected/locked)
Supports upgrades	❌ No	✅ Yes
IP protection (code)	❌ No	✅ Yes (obfuscated)
Namespace prefix	❌ No	✅ Yes (required)
AppExchange	❌ Generally no	✅ Yes
Uninstall	✅ (removes everything)	✅ (removes everything)
Ideal for	Templates, transfer between orgs	Commercial distribution, ISVs

Second-Generation Packaging (2GP):
- More modern managed packaging model.
- Compatible with Salesforce DX and source-driven development.
- Supports semantic versioning and better dependency control.
- Not a deep PAB exam topic, but you should know it exists.

AppExchange publishing process:
1. Develop the solution in a Developer Org.
2. Create a Managed Package with all components.
3. Submit the package for Salesforce Security Review.
4. Once approved, list on AppExchange.
5. Customers install from AppExchange.
6. Push upgrades when new versions are available.

Package installation:
- Installed using an installation URL or from AppExchange.
- When installing, choose: Install for Admins Only, Install for All Users, or Install for Specific Profiles.
- Dependencies must be satisfied before installation.

Key concept: If asked "how to distribute a solution to unconnected orgs" → the answer is a Package (not Change Sets, which require connected environments).