- Describe Salesforce.com and customer relationship management (CRM).
- Describe the basic functionality of the Sales Cloud and Service Cloud.
- Describe what editions Salesforce.com offers.
- Explain the concepts of cloud computing, multi-tenancy, and software-as-a-service (SaaS).
- Explain the different user interfaces available within Salesforce.com.
- Explain how to switch between Salesforce Lightning Experience and Salesforce Classic.
- Explain the difference between a field, object, tab, and record.
- Describe the following terms: application, page layout, list view.
- Describe the difference between data and metadata.
- Describe how to navigate the setup menu in Salesforce.com.
- Describe how to navigate to your personal settings in Salesforce.
- Describe the difference between standard and custom components.
- Describe the difference between production and sandbox environments.
- Describe the difference between a Salesforce environment, organization, instance, and pod.
- Describe where to monitor Salesforce.com system status.
- Describe options to get involved in the Salesforce Community.
- Explain how Salesforce provides new releases to their platform.
- Describe options for storing Salesforce.com credentials.
- Describe how to manage multiple concurrent sessions to Salesforce.com
- Learn the behind the scenes story of Salesforce.com origins and success.
- Overview – Module Checkpoint
Introduction to Salesforce sandboxes
Article
Should
Short
CertifiedOnDemand.com
What is a Sandbox?
A sandbox is a copy of a production environment used for a variety of purposes, commonly including testing and development.
Here’s how it works: When you create or refresh (essentially deletes and recreates a sandbox using the same name) a sandbox, a copy of the production environment at that point in time is made. The vast majority of the configuration remains the same as the production org. There are a few tweaks to sandboxes during the copy process – for example the sandbox name (e.g. Dev1) is appended to the username of all users within the sandbox. Some types of sandboxes will allow you to specify data to be copied from production into the sandbox as well (see Develop and Test with Sandbox for details). If no data is copied, then all of the configuration (metadata) will be migrated, but no records will be present in the sandbox.
What’s the goal?
Let’s say that I want to build a new Force.com application – I would start by building and testing that application in a sandbox. Once I am satisfied with the application, I can then migrate the metadata and data (if applicable) to the production environment. By performing this configuration in a non-production environment, I am free to test and experiment without running the risk of creating unused configuration/fields, interfering with an existing application in use, and other such concerns.
Many enterprise companies will use a multi-staged deployment methodology – the most common example is development and unit testing in one sandbox (usually a developer sandbox), promotion to QA (usually a full sandbox), then promotion to production.
Objectives for this Resource:
A sandbox is a copy of a production environment, commonly used for testing and development. Sandbox and production environments use different login URLs:
- Production Environments: https://login.salesforce.com
- Sandbox Environments: https://test.salesforce.com
If you know which pod your org is hosted on (see below), you can also login directly to this pod (for example, https://na38.salesforce.com). This is usually only helpful immediately after you’ve changed a username (it can take a few minutes for login.salesforce.com to reflect a username change) or there is an outage impacting user authentication.