Home Organization
A Home Organization is the primary Salesforce org that owns a user's identity in an enterprise that runs more than one org.
Definition
A Home Organization is the primary Salesforce org that owns a user's identity in an enterprise that runs more than one org. It is the org where the User record is created, where the login credential or Federation ID lives, where the license is consumed, and where password and session policy apply. Every other org the person reaches treats this org as the authoritative source for who they are.
The term turns up wherever one identity spans several orgs. With Salesforce Identity, the home org issues the SAML assertion that signs a person into a downstream org. In a hub-and-spoke or peer federation, it acts as the identity provider that the spoke orgs trust. In cross-org record sharing, queues and sharing references resolve a person through their home-org user ID. Pinning down the home org removes ambiguity about which org holds the real account.
How the home org anchors identity across many orgs
One User record, one authoritative org
A person can hold separate User records in several Salesforce orgs, but only one of those orgs is treated as home. That org owns the credential the person actually logs in with, whether that is a Salesforce username and password or a Federation ID supplied by an external provider. Profile, role, permission sets, password policy, and login-hours settings all apply in the org where the record lives. When the home org signs a person into another org through single sign-on, the downstream org does not store the password. It trusts a signed assertion that traces back to the home org. This matters for a simple reason: changing a password, freezing an account, or revoking access only needs to happen in one place to take effect everywhere. Treat the home org as the master copy of the human, and the spoke orgs as access grants that point back to it. Get this mapping wrong and you end up with several orgs each believing they own the same person, which makes offboarding slow and error prone.
The home org as SAML identity provider
When the home org authenticates people into other orgs, it plays the role of SAML identity provider. An admin turns this on from Setup by entering Identity Provider in Quick Find, selecting Identity Provider, and clicking Enable Identity Provider after choosing a certificate. Salesforce then exposes identity-provider metadata and a certificate that each downstream org imports. The spoke org is configured as a service provider that trusts the home org. A person who hits the spoke org gets redirected to the home org, signs in once, and lands back in the spoke with an active session. The browser session at the home org is what carries the trust, so a single login can open several orgs in one sitting. The certificate is the linchpin of that trust. If it expires without a planned rotation, every downstream login breaks at once, because the spoke orgs can no longer validate the assertion. Schedule certificate renewal well ahead of expiry and update each service-provider configuration with the new public certificate.
Federation ID as the cross-org join key
Inside a single org, a person is identified by their username or User ID. Across orgs, those values differ, so federated single sign-on needs a stable identifier that survives the hop. That identifier is the Federation ID, a field on the User record that holds the value the identity provider sends in its SAML assertion. The home org sends the Federation ID, and each spoke org matches the incoming assertion to a local User record by that same value. Salesforce makes the Federation ID case-insensitive by default the first time you enable SAML, which blocks near-duplicate values like csmith and CSmith from creating two distinct people. Keep the Federation ID consistent across every org, because it is the only field guaranteed to tie one human to all their accounts. A common pattern is to set the Federation ID to a corporate email or an employee number that the HR system already owns. When audit teams later need to reconstruct what one person did across orgs, the Federation ID is the value they join on.
Multi-org shapes that rely on a home org
Three common org topologies lean on the home-org idea. Hub-and-spoke puts one central org at the middle with regional or business-unit orgs around it, and the hub usually serves as the home org and identity provider. Peer federation links several orgs of roughly equal size that share a subset of users, where one org is still designated as the identity authority for each shared person. Acquisition and merger scenarios produce a temporary state where people span two orgs while systems are consolidated, and the home org defines whose credential is authoritative during the transition. In all three, the home org answers one question: when this person signs in, which org vouches for them. Picking the home org is an early architectural decision, not a setting you flip casually. The conventional choice is the org with the largest active user population, since reassigning the home org later means re-pointing identity-provider trust, re-issuing assertions, and reworking every spoke configuration. That is a project, not a quick change.
Cross-org record sharing and provenance
Salesforce to Salesforce is the older feature that lets two orgs publish and subscribe to records such as leads, opportunities, and custom objects. An admin enables it under Setup, creates a connection to the partner org, then chooses which objects and fields to publish or subscribe. People in the subscribing org see records that originate elsewhere, and the connection tracks which org and which owner the record came from. Here the home org of the original owner acts as provenance: it tells you the authoritative source of a shared record, which reporting and audit can trace back to. This is distinct from identity federation, but it leans on the same principle that one org is the source of truth. Newer integration patterns, such as Salesforce Connect with external objects or platform events, often replace Salesforce to Salesforce for fresh builds, yet the underlying need stays the same. When data crosses an org boundary, someone has to record where it really lives, and the home org of the owner is that anchor.
Licenses, audit, and the cost of getting it wrong
A person consumes a user license in their home org. If a spoke org also holds a real User record for them rather than relying purely on federation, that spoke consumes a license too. So a single human can cost several licenses across a multi-org estate, and the budget model has to account for that. Federation reduces friction for sign-in, but it does not by itself collapse separate User records into one license. Audit data compounds the point. Setup Audit Trail, Login History, and Event Monitoring are all per-org, so one federated person shows up in several audit streams. Compliance teams stitch those streams together using the Federation ID or home-org user ID as the join key, because that is the identifier that persists across the boundary. A practical move is to ship every org's audit events into one SIEM so investigators get a single timeline instead of logging into each org by hand. Plan licensing and audit consolidation up front, because retrofitting either onto a live multi-org deployment is painful.
Designate a home org by making it the identity provider
There is no New Home Organization button. You designate a home org by making it the identity provider that your other orgs trust. Do this work in the org you have chosen as home.
- Enable the home org as an identity provider
In the home org, from Setup, enter Identity Provider in Quick Find and select Identity Provider. Click Enable Identity Provider, pick a certificate, and save. Download the identity-provider metadata and certificate so each spoke org can import them.
- Set up each spoke org as a service provider
In every downstream org, go to Single Sign-On Settings, enable SAML, and create a configuration using the home org's metadata. Match users by Federation ID rather than username so the same value resolves the right person in each org.
- Populate the Federation ID on every User record
Set the Federation ID field on the User record in both the home org and the spoke orgs to the same stable value, such as a corporate email or employee number. The identity provider sends this value, and spoke orgs match on it.
- Test the login and plan certificate rotation
Sign in at a spoke org, confirm the redirect to the home org and a clean return, then add the SSO option to the spoke login page. Record the certificate expiry date and schedule renewal before it lapses.
The certificate the home org uses to sign assertions. Each spoke org imports its public half to validate logins, so rotation must be coordinated across all of them.
Tells each spoke org to match incoming assertions on the Federation ID field. Keep the case-insensitive default on to avoid near-duplicate identities.
A separate SAML Single Sign-On Setting in each downstream org that names the home org as its trusted identity source.
- An expired identity-provider certificate breaks every downstream login at once. Track the expiry date and rotate it on a schedule, updating each spoke org with the new public certificate.
- Federated sign-in does not merge licenses. A person with a real User record in a spoke org consumes a license there in addition to the home org.
- Reassigning the home org later is a major project. It means re-pointing trust and reworking every spoke configuration, so choose carefully at the start.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Home Organization.
Hands-on resources to go deeper on Home Organization.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the Home Organization in Environment Hub?
Q2. What's typically the Home Organization?
Q3. What does the Home Organization let you do?
Discussion
Loading discussion…