Salesforce offers four sandbox types, each suited to different stages of the development lifecycle. Developer sandboxes copy only metadata (configuration, code) with 200 MB of data storage and can be refreshed once per day; they are ideal for individual development and unit testing. Developer Pro sandboxes also copy metadata only but provide 1 GB of storage, supporting larger datasets for development and quality assurance; they too refresh daily. Partial Copy sandboxes include metadata plus a sample of production data defined by a sandbox template (up to 10,000 records per object, 5 GB total) and can be refreshed every 5 days; they are well suited for integration testing, user acceptance testing, and training. Full sandboxes replicate production entirely, including all data, attachments, and optionally field history and Chatter data, with storage matching production; they refresh every 29 days and are used for performance testing, load testing, and staging final deployments.

Refresh considerations are critical for administrators. Refreshing replaces the sandbox with a fresh copy of production, so any unmigrated changes in the sandbox are lost; always deploy or back up work (via change sets, packages, or source control) before refreshing. Refresh intervals limit how often you can resynchronize, so plan timing carefully around release cycles. Sandbox templates let you control which objects are copied into Partial and Full sandboxes, reducing refresh time. Post-refresh tasks often include re-enabling integrations, updating endpoints, and adjusting email deliverability since sandboxes default to System Email Only. User email addresses are modified with '.invalid' appended, and usernames gain the sandbox name suffix. Consider data masking for sensitive information in sandboxes that contain production data. Apex classes can run automatically after refresh using the SandboxPostCopy interface to automate setup. Finally, sandbox licenses vary by edition, so verify availability before planning environment strategy.

Change Sets are a point-and-click deployment tool in Salesforce used to migrate metadata (customizations) between related orgs, such as from a sandbox to production or between sandboxes that share the same production org. They are a core topic in the Platform Administrator II exam under Environment Management and Deployment.

An Outbound Change Set is created in the source org (for example, a Developer or Full sandbox). The administrator adds components such as custom objects, fields, Apex classes, Flows, page layouts, validation rules, permission sets, and profiles. Dependencies can be viewed and added using 'View/Add Dependencies' to avoid deployment failures. Once complete, the change set is uploaded to a target org. After upload, the change set becomes read-only and cannot be modified; a new one must be cloned or created for additional changes.

An Inbound Change Set appears in the target org (for example, production) after the upload. The administrator reviews the components and can click 'Validate' to run a test deployment without committing changes, which checks for missing dependencies and runs Apex tests. When ready, 'Deploy' applies the changes. Deployments to production require at least 75% Apex code coverage and passing tests.

Deployment Connections control which orgs can send and receive change sets. They exist only between orgs connected to the same production org (production and its sandboxes). In Setup, under Deployment Settings, an administrator must enable 'Allow Inbound Changes' in the target org for each specific source org. This authorization is one-directional, so each direction must be configured separately. Deployment connections cannot be created between unrelated orgs.

Key limitations: change sets cannot delete components or rename them, not all metadata types are supported, uploads can take time to appear, and certain items like standard picklist values or some settings must be migrated manually. Best practices include validating before deploying, deploying during low-usage windows, and documenting manual post-deployment steps.

Change Sets are the declarative tool Salesforce provides for migrating metadata between connected orgs, such as moving customizations from a sandbox to production. For the Platform Administrator II exam, understanding components and dependencies is essential because incomplete change sets are a leading cause of failed deployments.

Components are the individual metadata items you add to a change set, such as custom objects, custom fields, Apex classes, Visualforce pages, validation rules, workflow rules, flows, page layouts, record types, permission sets, profiles, custom tabs, apps, reports, dashboards, email templates, and Lightning components. Not everything is deployable; data records, some org-wide settings, and certain items like standard picklist values or Lead Assignment Rule order are not supported and must be configured manually in the target org.

Dependencies are the related components that a selected component requires to function. For example, a custom field depends on its parent object; a page layout depends on the fields, record types, and custom buttons it references; an Apex class may depend on other classes, custom objects, or custom settings; a report depends on a custom report type. Salesforce offers a 'View/Add Dependencies' button on the outbound change set, which scans your selected components and suggests related items. However, this detection is not exhaustive, so administrators must carefully review and manually add anything missed.

Key considerations include: profiles and permission sets only carry permissions for components included in the same change set; a deployment connection must be established between orgs with inbound and outbound authorization; change sets are validated in the target org, and any missing dependency causes the entire deployment to fail atomically. Best practices are to validate before deploying, use a consistent naming convention, document components, deploy in logical order (objects and fields first, then automation and layouts), and run Apex tests to meet the 75 percent coverage requirement for production.

Change sets are Salesforce's declarative deployment tool for moving metadata between connected orgs (e.g., sandbox to production) that share a deployment connection. Validating and deploying are two distinct steps every Platform Administrator II candidate should understand.

Validation: Before deploying, you can validate an inbound change set in the target org. Validation runs the full deployment process—including Apex tests—without committing any changes. This surfaces errors such as missing dependencies, failed tests, or insufficient code coverage (production requires 75% overall coverage, with every trigger having some coverage). Validating is strongly recommended because it catches problems without affecting users. A successfully validated change set can be 'quick deployed' within 10 days (as long as the target org's metadata hasn't changed), skipping the test run and reducing deployment time—critical for production releases during maintenance windows.

Deploying: Deployment commits the change set's components to the target org. Key points: (1) Deployment connections must be authorized in Setup under Deployment Settings, and they are directional—the target must allow inbound changes from the source. (2) Change sets are all-or-nothing; if any component fails, nothing is deployed. (3) Change sets are immutable once uploaded; to fix issues, clone and re-upload. (4) Components must include dependencies (e.g., a field's object, or a profile referenced by a flow). Use 'View/Add Dependencies' to include them. (5) Some items aren't supported (e.g., certain org-wide settings, data, Lead/Case assignment rule activation, standard picklist values), requiring manual post-deployment steps. (6) Test level options include Default, Run Local Tests, Run All Tests, or Run Specified Tests.

Best practices: deploy to a staging sandbox first, document manual steps, deploy during low-usage periods, and use the Deployment Status page to monitor progress and troubleshoot errors. Understanding these concepts ensures reliable, low-risk releases.

Change sets are a point-and-click deployment tool in Salesforce used to migrate metadata between related orgs, such as from a sandbox to production. However, administrators preparing for the Platform Administrator II exam must understand their limitations, because many configuration elements and all data are excluded.

First, change sets never move data. Records such as Accounts, Contacts, custom object records, or Chatter posts are not included. To migrate data, admins must use Data Loader, Data Import Wizard, or third-party ETL tools. Similarly, record-level settings like record ownership, queue membership, and public group membership are not transferred.

Second, many org-wide settings are not supported. These include organization-wide defaults, company information, fiscal year settings, currency settings, business hours, and most Setup menu toggles. Features like Sales Processes and Support Processes, Lead and Case assignment rule activation, and Web-to-Lead or Web-to-Case settings must be configured manually in the target org.

Third, certain security components are excluded or only partially moved. Users themselves cannot be deployed, nor can passwords, login IP ranges on profiles, or delegated administration settings. Profiles and permission sets can be included, but only the permissions related to components in the change set are deployed, so field-level security on components not included will not move.

Fourth, several customization items are unsupported: Email-to-Case settings, Account Teams and Opportunity Teams configuration, product schedules, territory configuration, Case Feed layouts, Console settings for some features, Outlook configurations, and multi-currency settings.

Finally, change sets only work between orgs with a deployment connection, such as production and its sandboxes, so unrelated orgs require Metadata API, Ant Migration Tool, or Salesforce CLI. Because of these gaps, admins should maintain a post-deployment checklist to manually configure excluded items, verifying the target org after each release.

In Salesforce, packages are containers used to bundle and distribute metadata components (objects, fields, Apex classes, flows, Lightning pages, etc.) from one org to another. For the Platform Administrator II exam, understanding the difference between managed and unmanaged packages is a key part of Environment Management and Deployment.

Unmanaged Packages are typically used to distribute open-source projects, templates, or starter configurations. Once installed in the subscriber org, the components become fully editable, just as if the admin had built them from scratch. The original developer has no ongoing control: components cannot be upgraded, patched, or versioned. If you need changes, you must manually modify or reinstall them. Unmanaged packages do not use a namespace prefix, so component API names remain unchanged. They are ideal for one-time deployments of configuration or for sharing sample apps between orgs, such as moving a prototype from a Developer Edition into a sandbox.

Managed Packages are primarily used by ISVs and AppExchange partners to distribute commercial applications. They are created in a Developer Edition org with a registered namespace prefix (e.g., npsp__), which is appended to every component to prevent naming conflicts. Key characteristics include: Apex code and certain metadata are hidden (intellectual property protection), components are locked so subscribers cannot modify or delete them, the publisher can push upgrades and patches, and managed package components do not count against most subscriber org limits (such as custom object or Apex code limits). Managed packages also support License Management, Trialforce, and version control. Second-Generation Managed Packages (2GP) built with Salesforce DX and the CLI further streamline this by linking packages to a Dev Hub rather than a specific packaging org.

For admins, the practical takeaway is: unmanaged packages give full flexibility but no upgrade path; managed packages provide protected, upgradable, supported applications with limited customization. Choosing between them depends on whether you need control and editability or long-term maintainability and vendor support.

Installing AppExchange packages is a core Environment Management and Deployment skill for the Salesforce Platform Administrator II exam. The AppExchange is Salesforce's marketplace where partners publish apps, components, and solutions that extend your org without custom development.

Packages come in two main types. Unmanaged packages are editable after installation and are typically used for templates or sample code; they cannot be upgraded and components count against your org's limits. Managed packages are developed with a namespace prefix, are locked (code is hidden and components cannot be modified), support upgrades and versioning, and often do not count against certain limits such as custom objects and tabs. Managed packages are the standard for commercial ISV apps.

Before installing, an administrator should review the app's listing, check the security review status, read the documentation, and evaluate edition compatibility, licensing model, and required features. Best practice is to install first in a sandbox to test functionality and integration with existing customizations. Note that many sandbox installs require the package to be installed via the AppExchange 'Get It Now' flow, choosing 'Install in Sandbox'.

During installation you must confirm the package contents, accept terms, and choose who gets access: Install for Admins Only, Install for All Users, or Install for Specific Profiles. For profile-based installs, you map package profiles or set object and field permissions manually afterward. You may also need to approve third-party access (remote site settings) for apps that call external endpoints.

Post-installation tasks include assigning licenses via Setup > Installed Packages > Manage Licenses, configuring custom settings or metadata, adding tabs to apps, updating page layouts, and granting permission sets. Managed packages can later be upgraded through push or pull upgrades, and uninstalling them removes their components while optionally saving a data export.

Understanding these steps ensures secure, governed adoption of AppExchange solutions across environments.

Release management in Salesforce is the disciplined process of planning, building, testing, and deploying changes from development environments to production while minimizing risk and disruption. For Platform Administrator II candidates, mastering this process is central to the Environment Management and Deployment domain.

Key best practices begin with a well-structured sandbox strategy. Use Developer or Developer Pro sandboxes for building and unit testing individual changes, Partial Copy sandboxes for integration and quality assurance testing with representative data, and Full sandboxes for user acceptance testing, performance testing, and staging that mirrors production. Refresh sandboxes regularly and align refresh schedules with release cycles so testing reflects current production configuration.

Establish a clear release cadence, such as weekly minor releases and monthly or quarterly major releases, and communicate the schedule to stakeholders. Maintain a release calendar that also accounts for Salesforce's three seasonal releases, and use sandbox preview windows to test upcoming platform features before they reach production.

Use appropriate deployment tools based on complexity. Change Sets work well for declarative metadata between connected orgs, while Salesforce CLI, Metadata API, DevOps Center, and version control systems like Git support more complex, repeatable, and auditable deployments. Always validate deployments before committing them, run relevant Apex tests, and verify that code coverage meets the 75 percent requirement.

Document every change with a change log, deployment checklist, and rollback plan. Note manual post-deployment steps that cannot be migrated via metadata, such as activating flows, updating picklist values in record types, configuring email deliverability, or adjusting profile settings and permission set assignments.

Finally, govern the process through a change advisory board or approval workflow, enforce least-privilege access to production, perform user acceptance testing with business stakeholders, and conduct post-release monitoring and retrospectives. Training end users and preparing communication ahead of each release ensures adoption and reduces support tickets after go-live.