How to Authorize a Salesforce Environment Locally? A Simple Guide for Salesforce Developers

Ever tried working on a Salesforce project and realized you’re not even connected to the org? Been there, done that. As a Salesforce DevOps Engineer, I’ve had my fair share of those “Oops!” moments. Whether you're just starting out or you're a seasoned dev managing multiple environments, knowing how to authorize a Salesforce org locally is a must-have skill in your toolbox.

In this guide, I’m walking you through different ways to authorize Salesforce orgs, what tools you need, and some handy best practices to keep your workspace clean and secure.

Pre-requisites

Before we jump into the how, let’s make sure you’re all set up. Here’s what you’ll need:

✅ Salesforce CLI (latest version)
Download it from the official site: Salesforce CLI Downloads

✅ Visual Studio Code (latest version)
VS Code is the go-to IDE for Salesforce devs.

✅ Salesforce VS Code Extensions
Install the Salesforce Extension Pack or Salesforce CLI Integration from the VS Code Marketplace.

✅ A Salesforce Project Created Locally
If you don’t have one yet, you can create a new project using:

sf project generate --name my-salesforce-project

Authorization Scenarios – Pick Your Style!

There are multiple ways to authorize a Salesforce org. Choose the one that fits your workflow:

1. Authorize Using VS Code Command Palette

This is the easiest method if you prefer clicking over typing.

Steps:

1. Open your Salesforce project in VS Code.

2. Press Ctrl + Shift + P (or Cmd + Shift + P on Mac) to open the Command Palette.

3. Type and select: SFDX: Authorize an Org

4. Choose the type of org (e.g., Production, Sandbox, Developer).

5. Enter an alias for easy identification (e.g., devorg, uat, prod).

6. Hit Enter – this will open your browser.

7. Log in with your Salesforce credentials.

8. Once successful, come back to VS Code and you’ll be connected!

That’s it — simple, no terminal needed!

2. Authorize Using sf org login web Command

Prefer using the terminal? No problem.

Steps:

1. Open terminal/command prompt inside your project folder.

2. Run:

    sf org login web --alias devorg --set-default
   

   • --alias gives your org a name.

   • --set-default makes it the default org for CLI commands.

3. This opens a browser. Login with your Salesforce credentials.

4. Once successful, the CLI will save your org and set it as the default.

Done and dusted!

3. Authorize Using sf org login device Command

This is handy for headless systems or remote servers where browser login is not feasible.

Steps:

1. In your terminal, run:

    sf org login device --alias devorg --set-default
   

2. You’ll get a code and a URL.

3. Open the URL in your browser, enter the code, and log in to Salesforce.

4. Once authorized, return to your terminal – CLI will handle the rest.

Perfect for servers or cloud workstations!

4. Authorize a Dev Hub

What is a Dev Hub?
Dev Hub is a special Salesforce org used to create and manage scratch orgs in SFDX projects. Without authorizing a Dev Hub, you can’t create scratch orgs — so it’s a must for SFDX-based development.

To authorize a Dev Hub:

sf org login web --alias my-devhub --set-default-dev-hub

Or, if you’re using VS Code, choose SFDX: Authorize a Dev Hub from the Command Palette.

Once authorized, you can create scratch orgs like a pro using:

sf org create scratch --definition-file config/project-scratch-def.json --alias scratchorg --duration-days 7 --set-default

Best Practices to Keep Things Clean and Safe

Here are some golden rules I follow (and recommend!):

1. Check Your Currently Authorized Orgs

sf org list

This will show all orgs connected to your local machine, along with which one is currently the default and default Dev Hub.

2. Logout from Unused Orgs

Keep your workspace tidy — too many connected orgs can get confusing.

sf org logout --target-org <alias>

For example:

sf org logout --target-org prod

3. Extra Precaution for Production Orgs

If you’ve connected your Production Org, make sure to:

• NEVER set it as default unless absolutely needed.

• Log out immediately after work using the logout command.

• Double-check sf org list before running any destructive command.

4. Bonus Best Practices:

• Use different aliases for each org (e.g., dev-org, qa-org, uat-org, prod-org) to avoid confusion.

• Always run sf org list before deployment or metadata pull to verify the target.

• Store all your org login aliases and purpose in a simple README or .env file in your repo.

• Use --no-prompt flag cautiously in CI/CD to avoid unintended behaviors.

• For CI/CD workflows, use JWT-based authorization (a topic for another day!).

Wrapping Up

Authorizing Salesforce environments locally might seem like a small step — but it’s a crucial one. It sets the stage for everything that follows: deploying metadata, running tests, pushing to scratch orgs, and automating releases.

Pick the method that works best for your workflow, stay organized with aliases, and double-check before deploying — especially when the word “production” is involved! 😅

I hope this article made your Salesforce journey a little easier. If you found this helpful, feel free to leave a like, share it with your dev buddies, or drop a comment with your own tips!

Until next time — Happy Coding, Trailblazer! 🚀