As an ISV partner I find myself juggling a bunch of username/passwords for my SFDC orgs.

I have our "real" org where we do our own CRM related stuff. I have multiple dev orgs where we create our managed packages. We have orgs we use to demo. We have the partner portal. Sometimes we have direct logins to customer production orgs and sandboxes (this is less frequent now that they can grant us login access through our apps). How do you manage all these usernames/passwords, especially with many of them wanting to be changed via password policies?

Is there 3rd party software that makes this easier or something within Salesforce itself that I'm simply unaware of?

13 Answers 13


Use a password management tool like 1Password, Lastpass, or KeePass. I believe all of them have desktop apps, browser plugins and mobile apps with database syncing in one form or another (such as DropBox).

I prefer 1Password as it's plugins make it very easy for me to use multiple logins for the same site. When I go to login.salesforce.com I hit a hotkey and it shows all my SalesForce accounts and if I begin typing it searches the account names, then I can arrow down and hit enter (or just hit enter if there's only one result) to log in.

It's the only sane way I've found to manage 50+ Salesforce accounts easily.

  • I prefer KeePass, which doesn't host the passwords in the cloud, and can be used in any browser (or many, simultaneously) without installing lots of plugins.
    – Benj
    Commented Aug 17, 2012 at 20:22
  • 1Password doesn't store the passwords in the cloud either, but you can do that if desired by using DropBox and their mobile apps integrate with DropBox to sync if needed. The mobile app can also sync to your desktop client over Wifi if you want that ability without having your data in the cloud. 1Password also has a single desktop app you install and it manages the plugins for all browsers. So in that aspect they sound pretty similar. However, 1Password costs money and KeePass is free. Commented Aug 17, 2012 at 20:25
  • 1
    And Open Source!
    – Benj
    Commented Aug 17, 2012 at 20:26
  • Password Safe (passwordsafe.sourceforge.net) is another option but again it doesn't store data in the cloud natively. Commented Oct 19, 2012 at 8:55

I noticed in the Winter 13 release notes (page 204 of the PDF) there is a mention of "Environment Hub (pilot)". Worth keeping an eye on.

Starting in Winter ‘13, you can use the Environment Hub to view details of all your Salesforce organizations from one, central location. This can make administration much easier, especially for companies that use a large number of organizations for development and testing.

From the Environment Hub, you can:

  • Register all organizations currently used by your company
  • Automatically detect relationships between organizations
  • View details about each organization, such as its type (for example, Development, Patch, or Release) and tags
  • Assign one or more tags to any organization
  • Filter organizations by tag

Environment Hub online help


I use the Google Chrome plugin: Force.com Logins

Not very secure, but easy for poping between a lot of orgs very quickly!

Also easy to export and import large sets to an XML document for easy transport.

force.com login manager

  • Big fan of this plugin. Commented Aug 22, 2012 at 3:24
  • One word of warning, it puts your password unencrypted in your browser history (logs you in by opening a new tab to login.salesforce.com/?un=username&pw=password). It's undoubtedly quite useful but I'm wary of putting my production credentials in. Commented Oct 19, 2012 at 3:43
  • 1
    salesforce's lack of a comprehensive security model for developers whom have to maintain dozens of orgs is the reason security flaws like this exist. it's the only practical way. Commented Oct 19, 2012 at 4:02
  • (super late reply) You can POST the same parameters (un and pw) so that it doesn't leave them in your history. Commented Oct 29, 2013 at 20:48

I use superfell's excellent Trapdoor for the Mac (stores the org credentials in the Mac Keychain, so it's pretty secure). On the PC, there are any number of browser-based password managers.

In a more permanent, 'production' setting (you actually want to make an SSO link between two orgs), you could do org-to-org sign on with SAML or Authentication Providers.

  • 1
    God I love Trapdoor. Assuming the team is all on mac, you could use dropbox to keep a keychain file in sync across everyone in the group. Been meaning to try it. Commented Nov 28, 2012 at 2:56
  • 1
    Can't believe I didn't know about this before now. Always hated the chrome plugin for obvious security issues, but used it because i needed a viable solution to 20+ orgs to handle. just got trapdoor, love it. Thanks for this. How did I not know about this? lol Commented Oct 29, 2013 at 18:29

We use a Google Spreadsheet to handle lots of orgs (development, QA, packaging, patch, etc). In addition to usernames and passwords, we also store Org Ids (useful for finding an org in the subscriber console or when pushing patch updates), tokens (useful for logging in via the API), Salesforce instance (useful for telling what org may be affected by something going on at Salesforce, i.e. upgrades, maintenance, service disruption, etc), and a formula to create a login link:

="https://www.salesforce.com/login.jsp?un=" & trim(C4) & "&pw=" & trim(D4) where C4 is the username and D4 is the password.

  • Nice - I like the formula to create the link!
    – metadaddy
    Commented Aug 18, 2012 at 1:34
  • What do you do about different orgs
    – H20rider
    Commented Aug 8, 2014 at 16:42
  • Not sure I understand your question.
    – Rob Scott
    Commented Aug 8, 2014 at 20:39

I personally use LastPass for this and haven't really looked back. https://lastpass.com/

It makes it a lot easier for me since I use a lot of machines and LastPass keeps all of them in sync.


Just to let you know that I have now used the environment hub. You do need to ask for it to be implemented (as it is strong magic). Once set up, you identify one of your orgs as the hub. You link to other orgs by giving a username to that org. Finally you map logins from the hub to logins to the linked org. If you then switch on Single Sign On you can just click 'login' to be logged into the other org. It also allows you to spin up new test orgs.

Just a comment... if you are using a browser based password manager, you have to be aware that they can be extracted, easily, with commonly available tools. I'm for encrypted storage, 2-factor authentication.. it may be a faff, but better than explaining to all your clients that your (admin) passwords are all in the wild!


You all are way more advanced than I am. I have a very long Google Spreadsheet.

  • As it stands, this isn't terribly helpful - is this a technique you'd actually recommend?
    – Shog9
    Commented Aug 19, 2012 at 19:26
  • It depends on if you are looking for a solution to track 50-100+ you logins or just a plugin to auto-login for you across a few orgs. I don't keep client information there, but I definitely trust the security around my Google spreadsheet and have it wherever I go. Similar to what metadaddy mentioned above, but admittedly less sophisticated.
    – Nick Hamm
    Commented Aug 21, 2012 at 2:38

We use 1Password to manage usernames/passwords of customer orgs. The only issue I have is that it requires everyone on the team to update each other when a password expires. As it solves the problem of remembering usernames and passwords - it creates an issue when you start doing team development.


I use browser bookmarks. You can append the username & password to the URL and save as a browser bookmark.

Name: Salesforce Org ABC
URL: https://login.salesforce.com/[email protected]&pw=mypassword

where username = [email protected] and password = mypassword


Ive been syncing passwords with dropbox and keepass with a 2 factor authentication for a couple years now and it works like a charm. I've started using the force.com logins plugin for chrome as well due to its one click operation and ease of use. since that plugin became the primary, I export the logins every now and then and store them in keypass should I be on another machine and need a clients password.


Just want to add the Chrome Extension I've recently published, the Salesforce ORGanizer https://chrome.google.com/webstore/detail/salesforce-organizer/lojdmgdchjcfnmkmodggbaafecagllnh, which includes credentials saving, easy links, tab icon color change (ease tab recognition) and a developer console on every Salesforce tab opened....and more coming in the next releases http://salesforce-organizer.enree.co


Remember them. Not being facetious, allow me to elaborate. I typically have 2 roots in a password, lets call them R1 and R2. Now if I'm logging into to a production org for client1, my password will be R1client1R2 If it's their sandbox called dev it'll be R1client1R2dev

So remembering the two roots for my passwords I just need to know where I am logging in to.

This can be expanded for personal logins else where, for example my stack exchange password I might use SE with the roots to give R1SER2. With R1 and R2 being 10+ characters each, you're quickly reaching password length that is not brute forceable in any realistic time frame.

This now satisfies a number of important criteria for passwords - Use a different password for each site. - Use passwords which are easy to remember ( you have only 2 roots to remember). - Use passwords which are not easily brute forced (i.e. long).

  • The problem with this approach is that Salesforce makes you change your password on an interval. If you have 10 different orgs, all requiring you to change the password at different times it gets out of sync really quickly unless you go and change all of them whenever it changes. Even then you have to remember which "version" of the password you are on. If you didn't have to change your password this would be a viable strategy. Commented Aug 18, 2012 at 16:38
  • Doesn't that make your passwords easier to break by brute force? You are reducing the entropy in the password considerably by using the client name. Commented Oct 19, 2012 at 8:54
  • 1
    This would only work if you absolutely never share your password with someone else, since knowing just one systematically-created password means knowing others. Commented Oct 20, 2012 at 15:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .