Salesforce Org

An org (short for "organization") is the individual, isolated instance of Salesforce that belongs to a company. It is the logical container that groups everything for that customer: its data records, its users, its configuration, its custom objects, its code and its integrations. When someone says "I changed it in the org" or "we have two orgs," they mean this unique, bounded space.

Although Salesforce runs as a multi-tenant platform (many companies share the same physical infrastructure), each org is logically separated from the rest: no customer sees another customer's data. That boundary is the basic unit on which a solution on Salesforce is implemented, governed and maintained. Each org has its own Org ID (a 15- or 18-character identifier) that distinguishes it from any other org in the world.

Understanding what an org is matters because it defines the scope of almost everything: platform limits (governor limits) are counted per org, permissions are assigned per org, and a migration or a deployment always targets a specific org.

What an org includes

An org is not just "the Salesforce account": it is a company's entire universe inside the platform. In practice, an org contains:

• The data: accounts, contacts, opportunities, cases and every record in Salesforce objects, both standard and custom.
• The users, with their licenses and the profiles and permission sets that define what each person can see and do.
• The configuration and customization: fields, layouts, automations built with Flow, code in Apex, components and reports.
• The integrations and messaging: connections to external systems via API, packages installed from AppExchange and the compute limits (the governor limits).

All of this lives under a single Org ID. If a company deletes an object in its org, that change does not affect any other org on the planet.

Why the concept of an org matters

The org is the governance boundary of any Salesforce project. When a consultant talks about a customer's "org strategy," they are deciding something structural: how many instances the company will have and how they relate to each other. That decision shapes cost, maintenance complexity and how quickly changes can be made.

It is also key for security and compliance. Because isolation happens at the org level, a company operating in several countries sometimes weighs whether a single org for the whole group makes more sense, or multiple orgs separated by business unit or region. There is no universal answer: it depends on how much the processes and data have in common.

Types of orgs you will hear about

Not all orgs are the same. It helps to distinguish the main ones:

The most important distinction day to day is production versus sandbox: you never test something new directly in production; you first validate it in a sandbox, which is a test org derived from the real one.

Single-org vs. multi-org: the typical dilemma

A frequent question at mid-size and large companies in the region is whether to concentrate everything in one org or split it across several. The difference is real, and it is worth being clear about it before implementing:

The general trend in new projects is to prefer a single org when business processes are similar, because it moves you closer to a single source of truth and simplifies governance.

A concrete example in Argentina

Consider an Argentine consumer goods company that sells to supermarkets and also exports to Uruguay and Chile. If it chooses a single org, its sales team sees local and export accounts in one place, shares the same dashboards and applies the same automations. If instead each subsidiary requested a separate org at some point, consolidated reporting for the group becomes a headache: data has to be extracted from each org and unified outside of them. That is why, before implementing, the consultant's first job is to properly define the org model.

Common mistakes

• Confusing an org with a user or a license: an org has many users; a user belongs to one org. They are not the same thing.
• Testing in production: making changes directly in the real org instead of validating them in a sandbox first.
• Creating new orgs without a strategy: ending up with several orgs without having planned it, and then being unable to consolidate the information.
• Ignoring governor limits per org: forgetting that compute limits are counted per org and designing integrations that push against them.

In short, the org is the structural piece every Salesforce project defines first. Knowing what it contains, which types exist and when one or several make sense is the foundation for an orderly implementation, and for the company to end up with a single source of truth instead of data silos.