"Salesforce Orgs" is the area of the Elements.cloud platform containing information about Salesforce Orgs that have been connected to, and scanned by Elements.cloud.
It all starts with connecting Elements.cloud to a Salesforce org and allowing it to scan the org.
The results of a scan are organized into an index and then enhanced with significant amounts of relevant data about the org, what parts it's comprised of and how those parts are put together being chief among them.
The presentation layer of the index is called the Metadata Dictionary because like a dictionary it's logically organized, making it navigable, and it provides relevant definitions, relationships and many more insights about the items listed in it. Unlike most dictionaries though, Elements.cloud can automatically update the Metadata Dictionary on a daily basis and will even make note of changes since the last sync.
All of this helps ensure that admin teams are working with the same up-to-date information when researching an org, making information easy to find and adding no undue burden to anyone to maintain it.
Admittedly, it's a big topic and this article doesn't tackle the whole thing, rather it delivers a foundational understanding of how Org Models are organized so you can navigate it and find relevant insights more quickly.
Other related articles deep dive into the Org Model content and features but those details are easier to understand once you've mastered these basics.
Metadata dictionary high-level structure
Managed packages structure
In order to use this feature you will need:
Locating the Org Model(s)
You will find your org model(s) located under the "Salesforce Orgs" global navigation icon on the left side of the screen.
You open an Org model by clicking on the blue name.
When you open an org model, you are presented with a list of metadata, also commonly referred to as a metadata dictionary. This list and its features are carefully curated and optimized for quick navigation, analysis, and facilitating actions based on the information it contains.
Understanding the Metadata dictionary's organizational structure
Org Models, by default, are presented in two columns on the main index screen. The left side of the screen is a navigable list of metadata categories, and the right side reflects details about what you've selected on the left.
Opening the org model presents you with the highest-level view, showing both counts of metadata categories (right-side) as well as lists of items found (left-side).
The left-side list is curated into two main sections: a top section and a bottom section. The top section lists unmanaged components, and the bottom contains managed components.
However, if there are no installed managed packages, you will not see a Managed Packages entry, and as such, the bottom section will not exist—you will only have a top section.
The top section
The top section shows a list of unmanaged metadata types found in the org and is sorted alphabetically. The exception to this sort order in the top section relates to "Objects."
We have nested three types of objects under this header and sub-grouped them for easier navigation. The "Objects" entry can contain:
Each of these categories is further divided into object names, each of which contains lists of related metadata types. This method imitates the Salesforce setup experience in Object Manager in terms of grouping related fields, validation rules, etc., but with added efficiency for exploring, as you'll see.
In the screenshot below, the row "Accounts" is selected, and the right sidebar has updated to show counts of related metadata types associated with the object. In this context, "related to" indicates that the listed items are components that "belong to" or "are on" the object. It's worth noting that dependency refers to the relationships between different components and how they interact within the Salesforce Org. We will discuss dependency and dependency analysis in more detail later.
The list of object-related metadata types can be seen in the image above on the right side, essentially telling you how many of each item you'll find if you explore the list on the left.
On the left-side index, you'll notice that metadata categories with bold lettering and a carrot icon contain further details. These indicators suggest that the category has sub-components or related items within it. For example, when you see a bold entry with a carrot icon, like "Objects," it signifies that this category encompasses various types of objects, such as Standard Objects, Custom Objects, and Custom Metadata. In contrast, standard, non-actionable text is used for categories without any associated items or sub-components. So, when you encounter such text, it means the category doesn't contain any further details.
In the example below, we are highlighting a picklist field entry named "Co-Termination Event." As part of the visual format, the picklist field contains sub-components, specifically picklist values. The screen displays the carrot icon, indicating that the sub-components have been expanded and their related picklist values are now visible. Additionally, notice that the right sidebar has been updated to display field-specific information, and it is no longer showing aggregation counts.
The bottom section
The bottom section begins with the last entry of the index, labeled "Managed Packages," which includes all the managed packages detected and their related metadata components.
Managed packages are presented similarly to Objects, listed by package name, and containing nested lists of related metadata—think of it as the package manifest. You can explore each component in detail.
We separate this list to make it easier to distinguish between unmanaged components (standard or custom-built) and managed components, which require different considerations as they are largely not customizable.
It's worth noting that in the default Metadata Dictionary, managed components, like fields, installed on a Standard or unmanaged custom object will be listed with the unmanaged component they relate to. For instance, the field shown in the screenshot above is part of the Salesforce CPQ package and is listed in the index on the standard object it was installed on.
You might also be interested in
Connecting and Syncing Salesforce orgs - for more information on organizing your synced orgs and making the connections
Quick start video - for setting up a space, including connecting Salesforce Orgs
Custom Views of Metadata - to explore how to create your own curated views of the Metadata Dictionary
Reports - to learn about Elements.cloud report collection