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.

Introduction to Salesforce sandboxes

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.