As I venture into the Salesforce Universe myself there are many areas that I would have wished had been easier to figure out. So what better than remedying that with a series of blog posts. Maybe there will be one post and maybe more. We’ll see… This first instalment is on some of the basics in Salesforce namely the org, sandboxes and some of the security implications of logging in. I’m pretty technical so some of this will be from a technical angle so please forgive me and stay with me.
“Org”
When you get provisioned a Salesforce instance – or an org as we like to call them – you get your own slice of the Salesforce infrastructure. Depending on the amount of data you add to the org the slice may be VERY small or VERY big but the core concept is the same. Every org has an identifier (the “org id”) and that is what identifies it and the associated data throughout the Salesforce infrastructure. Everything you do in your org – data and customizations belongs to your org due to being coupled to your org id.
Boom! That’s it.
Sandboxes
A sandbox is something you may or may not get depending on the license types you buy and depending on the type of licenses you may even get more than one. Sandboxes are play areas that are connected to your org and allows you to develop and test customizations and – maybe – eventually move these customizations to your production org. Sandboxes come in different flavours and may contain no actual production data, some data or all of your production data. We call these empty, partial and full sandboxes. A sandbox always contains the customizations from the org it was generated from.
Besides the customizations a sandbox also gets a copy of all the users from the “source org” although the email addresses of users are changed in the process by removing the @-sign and appending @example.com. Bringing all the users across means that users may log into the sandbox using their existing username and password – the only change they need to do is to append a period and the name of the sandbox. So if my username is jdoe@acme.com and I’m logging into a sandbox called “uat” I simply use the username jdoe@acme.com.uat and my password.
Customizations may be moved between a sandbox and an org using a “change set” which basically is our way to move customizations between environments. There are other ways as well for more advanced uses but let us keep it simple for now.
Logging in
At Salesforce our number one value is trust. The trust of our customers and the trust they place in us to keep the data they entrust with us safe. This means we spend a considerable amount of time and resources keeping data secure and ensuring that no two orgs get mixed up. It also means that Salesforce offers a number of ways to make sure only the right people may log in and do that at the right time of the day.
These security features come in a number of flavors including but not limited to:
- Username and password (duh!) and being able to set the complexity required of passwords.
- Whether two factor authentication is required using either the Salesforce Authenticator app, login codes texted to your cell phone or emailed to you.
- Which users may log in from what IP ranges and at what time of the day. If a user is assigned to a call center chances are they should only login from the call center location between 9am and 6pm.
- What IP ranges are deemed trusted. A login from a trusted IP range is special in that it doesn’t require a second factor of authentication (that is besides username and password).
Besides these there are loads of other security mechanisms – way too many to dive into here in detail. If interested head over to Help & Training or get friendly with the security related pages under Setup in an org.
Security and the API’s
Authenticating to the various API’s for Salesforce is slightly different from logging in to the web UI or Salesforce1 (our mobile app). As a developer, you need to know the type of org (production or sandbox) you’re working against If you need to authenticate using the API’s. The main reason is due to any login IP restrictions you may have configured for your production org but really it’s not important to know why. Simply remember that when using API’s and you need to log into a production org you use login.salesforce.com and If logging in against a sandbox you use test.salesforce.com.
It’s that simple. Use test.salesforce.com for – well – testing. So if using OAuth and logging in to a production org you use https://login.salesforce.com/services/oauth/token and If logging in against a sandbox use https://test.salesforce.com/services/oauth/token.
And really that’s all there is to it.
Security Tokens
This is the final piece for this post but an important one. Remember those IP ranges that may have been set up as trusted in your org? If not go back and find that section and read it again… Salesforce uses the security token as a second factor of authentication if you are attempting to login from a source that Salesforce doesn’t not quite trust. For interactive logins the second factor is either a code from Salesforce Authenticator or similar but for API logins the second factor is your “Security Token”.
Think of the security token as:
- An extra password that Salesforce issues to you (you cannot set it manually)
- That gets reset whenever you change your password
- Which is only ever revealed to you once. If you lose it, you may reset it from your personal Settings at which point the new one gets revealed to you.
Using the security token is very easy – you just append it to your actual password and use the resulting string as you normally would the password. As a super password if you will.
If you are lucky enough to be a developer and log into Salesforce using the API’s the security token is important to you as you may need to use your password/security token combo instead of your actual password. Again only if logging in from an untrusted network range such as when working from home without VPN or from Stackbucks.
For more information from the authoritative source of all things Salesforce I recommend reading through the posted titled Security and the API.