Salesforce orgs grow into thousands of fields, rules and automations that nobody fully remembers, so I built Data Dictionary to document them automatically. It reads the metadata straight from your Git repository and turns it into searchable, always-current documentation inside Salesforce itself: objects, fields and relationships; automation like flows, triggers and Apex classes; and the security model around them. ERDs, dependency maps and generated docs, all on demand. No spreadsheets, no separate wiki, no context switching, and nothing goes stale.
2GP native packaged appGit reads your repo metadata07 lightning viewersERD diagrams on demand
Most Salesforce teams document their org in spreadsheets and wiki pages. Those go stale the moment they are written, and nobody owns keeping them current.
Data Dictionary takes a different source of truth: the metadata your team already keeps under version control. It connects to the repo, reads the force-app source, and builds a complete picture inside Salesforce: every custom object, field and relationship, plus the automation and security layers around them.
Everything then surfaces through native Lightning components on a dedicated Data Dictionary app: searchable explorers, ERDs, dependency maps and generated documentation, all on demand.
metadata_surfacethe types the cache reads
01Objects, fields, relationships and dependencies
02Flows, triggers and Apex classes
03Profiles, permission sets and record types
04List views, custom labels and queues
05Connected apps and installed packages
Repo as source of truth
Reads metadata straight from your Git repository, so the documentation reflects what is actually under version control, not someone's recollection of it.
Native Lightning
Built as a 2GP managed package with its own namespace, so it runs entirely inside Salesforce. No browser extensions, no external apps, no separate login.
Rebuild, don't rewrite
Refreshing the picture is a cache rebuild, not a documentation project. The bigger the org, the more that saves.
the_tour[02]
The Dictionary, Toured
Four tours of the app. The Metadata Explorer, ERD viewer, the Dependency Viewer and Documentation viewer.
Demos[04 tours]
The Metadata Explorer, the ERD viewer, the Dependency Viewer and the Documentation viewer, each walked end to end. These are full-size Salesforce screens, so the tours play full screen where they can be read.
The tours are full-size Salesforce screens and need the room. Open this page on a desktop or tablet to watch them.
Demos
1Integration Setup. Guided Git connection: provider, repository, branch and credentials, with a live connection test.
2Application Configuration. Metadata styles plus UX, type and column settings, driven by Custom Metadata.
3Repository Explorer. Readme, branches, commits and pull requests, browsed from inside the org.
1One tab per type. Assignment rules to record types, each a searchable table from the cache.
2Custom Fields. All 207 custom fields with type, flags and relationships in one view.
3Scope to an object. The object picker narrows the table to a single object.
4Account only. 79 Account fields: API name, label, type and flags at a glance.
5Live search. Typing narrows 14 matches to one before the word is finished.
1The org as a diagram. Objects and relationships drawn from the cache, colour-coded by type.
2Filter the diagram. Object search, type toggles and relationship filters, with PNG export.
3Inspect an object. Fields, relationships and attributes in a panel beside the graph.
4Right-click to act. View details, focus, hide, or copy the API name.
1The whole org at once. Every component and reference in one zoomable, filterable map.
2Zoom in. Four beats from 6% to 80%, Account's neighbourhood resolving out of the blur.
3Click to inspect. The inspector lists 20 typed, directional connections.
4Double-click to focus. The map redraws as a fan around Account.
5Right-click for the menu. Metadata Overview, Grouped View, or copy the API name.
6Grouped View. One click redraws the map as five counted groups around Account.
7Open a group. RecordType fans out its eight record types.
8And the next. ApexClass opens to the two classes that touch Account.
9Traverse. Double-click a member and the map re-roots on its perspective.
10Its own census. The class's objects fan out, Account and Contact among them.
11Full circle. Double-click Account and the grouped census returns.
12The menu again. One more right-click on the root, and Metadata Overview is the pick.
13Metadata Overview. Everything connected to Account, charted by type over an expandable tree.
14Expand a type. RecordType unfolds to all eight names.
15And another. ApexClass unfolds to both test classes.
16The list is live. Double-click a class in the tree and the map re-roots on it.
1Documentation. Pages from the repository, rendered natively inside Salesforce.
2The navigation tree. Every page in the repo's documentation folder, refreshed on demand.
3Rendered pages. Markdown as rich text, with syntax-highlighted code blocks.
4A synced outline. Headings that track the reading position and jump on click.
architecture[03]
How It Works
The Git repository is the source: Bitbucket, GitHub, GitLab, Azure DevOps or AWS CodeCommit, with Bitbucket the default. Named and External Credentials handle authentication. Apex fetches and parses the metadata, with large runs chunked through a Platform Event so they never hit governor limits. The parsed result is cached in custom objects and rendered by Lightning Web Components.
Source & Sync
Git + Apex
External and Named Credentials authenticate to the Git provider, with a provider factory covering Bitbucket, GitHub, GitLab, Azure DevOps and AWS CodeCommit behind one interface. The repository and sync Apex layers pull the metadata source and parse it. A Platform Event continuation pattern breaks large repos into chunks so a full build stays within limits.
Data Layer
Cached in Custom Objects
Parsed metadata is stored in Repository_Metadata_Cache__c, with each build tracked in Repository_Metadata_Run__c. Custom Metadata Types control which metadata is read and how columns are displayed.
Presentation Layer
Lightning Web Components
Seven viewers render the cache: Metadata Explorer, Dependency Viewer, ERD Viewer, Documentation Viewer, Repository Explorer, Integration Setup wizard, and Application Configuration. Integration Setup provides guided credential configuration; Application Configuration manages presentation settings. They live on the Data Dictionary app and can be dropped onto any Lightning page in App Builder.
documentation_pipeline[04]
Confluence to Salesforce, Through Git
The Documentation Viewer is not limited to auto-generated reference material. It also renders real docs pulled from the same repository, and those often start life in Confluence. The Developer Tools VSCode extension exports a Confluence space to Markdown, a developer commits it alongside the metadata, and Data Dictionary picks it up on the next refresh through the same repository connection used for everything else.
flowchart TD
A["Confluence space pages + images + attachments"] --> B["VSCode: Developer Tools Confluence Export wizard"]
B --> C["Storage XML to Markdown (turndown) images/ mirrors the page tree"]
C --> D["git commit & push force-app documentation folder"]
D --> E["Git repository (Bitbucket / GitHub / GitLab / Azure DevOps / AWS CodeCommit)"]
E --> V["Documentation Viewer (LWC) Refresh"]
V --> F["DocumentationDiscoveryQueueable walk tree, collect .md paths"]
F --> G["DocumentationContentBatchQueueable fetch content in batches"]
G --> H["DocumentationImageService resolve & cache images"]
H --> I["Upsert Documentation_Page__c"]
I --> V
%% Blueprint tokens as literal hex (Mermaid cannot parse CSS vars or color-mix)
classDef apex fill:#8b93e81f,stroke:#8b93e8,stroke-width:1.5px;
classDef lwc fill:#62d99a1f,stroke:#62d99a,stroke-width:1.5px;
class F,G,H,I apex;
class V lwc;
Indigo nodes are the same Apex layer that parses metadata elsewhere on this page; green is the Lightning Web Component that renders it. Everything left of the Git repository happens outside Salesforce, in the same repo the metadata sync already trusts.
capabilities[05]
The Viewers
Metadata Explorer
Browse the Entire Configuration
A searchable view of the full metadata surface straight from the repo: every object, field, automation and security layer. Filter by type, then read each item's API name, label and key attributes without opening Setup or VSCode.
ERD Viewer
Relationship Diagrams On Demand
Entity-relationship diagrams generated from the cached metadata, showing lookup and master-detail links across standard and custom objects. Rendered with Cytoscape.js with selectable layouts (hierarchical, breadth-first, circle, grid) and a resizable inspector panel. Useful for design reviews without hand-drawing diagrams that are out of date by the next sprint.
Dependency Viewer
See What Touches What
Trace relationships and references between components with a minimap, zoom/drag, right-click context menu, and collapsible inspector panel. The kind of exploration interface usually found in dedicated diagramming tools, built natively in Lightning Web Components.
Documentation Viewer
Generated, Readable Docs
Read generated, structured documentation with a Markdown renderer, syntax highlighting, and a synced outline. Readable technical reference for the whole team, regenerated from the repo rather than maintained by hand.
Repository Explorer
Browse the Source Tree
Navigate the connected repository's metadata directly inside Salesforce, with each build's run history and status visible so you know exactly what the cache reflects.
App Configuration & Integration Setup
Point It At Your Repo
Guided setup screens connect the repository integration and tune what gets read and displayed, driven by Custom Metadata Types rather than hardcoded values. Errors are captured in Error_Log__c for troubleshooting.
audience[06]
Useful to Everyone on the Team
The same cached picture serves different people in different ways, from the first scoping conversation through to support years later.
DEV
Developers
Look up an API name, check what depends on a field, and understand existing patterns before writing code, without leaving Salesforce.
ARCH
Solution Architects
Generate relationship diagrams for design reviews, validate relationships, and spot reuse opportunities before adding new objects.
BA
Business Analysts
See what already exists when mapping requirements, and avoid asking for fields the org already has.
QA
QA & Testers
Use the relationship and field reference to design test scenarios that cover the objects a change actually touches.
ADM
Administrators
A current inventory of configuration to refer to, instead of clicking through Setup to remember how something was built.
SUP
Support Teams
Look up field context and relationships when triaging an issue, with fewer escalations to the dev team just to ask what a field does.
MGR
Project Managers
A clearer read on complexity for estimates, and faster onboarding for anyone joining the project.
SLT
Stakeholders & Clients
Visual relationship diagrams make the design legible to non-developers, and the knowledge stays in the platform when people move on.
business_value[07]
Documentation that rebuilds itself
Data Dictionary builds the picture from the repo, so the value comes from never having to do that work by hand again.
A traditional data dictionary is a deliverable. Data Dictionary treats the same information as a build output, generated from the metadata already in your repo.
Hand-maintained documentation
01Costs real effort to write in the first place
02Out of date the moment the next change ships
03Needs an owner and ongoing upkeep to stay useful
04Walks out the door when that person leaves
05Lives in a separate tool, so people stop checking it
Data Dictionary
01Connect the repo once, then rebuild on demand
02Reflects what is actually in version control
03Refreshing is a cache rebuild, not a writing task
04Knowledge stays in the platform, not in one head
05Native Lightning, so it is there when you need it
where_it_helps[08]
Value across the build and support lifecycle
BUILD
Development
Custom objects, fields, automation and integrations
What it gives the team
01Field and API name lookup without leaving Salesforce
02Dependency view to check what a field touches before changing it
03Existing patterns visible, so people build on what is there
Why it matters
01Less time hunting through Setup and source
02Fewer surprises from unseen dependencies
03Less duplicate metadata created by accident
TEST
Testing & QA
Functional testing, integration testing, UAT
What it gives the team
01A clear map of relationships to test around
02Field-level reference for building test scenarios
03Visibility of what a change actually affects
Why it matters
01Test coverage aimed at the objects that matter
02Fewer integration paths missed
03UAT starts from a clearer picture
SUPPORT
Go-Live & Support
Deployment, hypercare and ongoing support
What it gives the team
01Field context and relationships at triage time
02A current reference for whoever is on support
03Diagrams on hand for handover conversations
Why it matters
01Support answers more questions without the dev team
02Faster answers during the highest-pressure period
03Knowledge survives handovers and team changes
EVOLVE
Maintenance & Evolution
Enhancements, scaling and new integrations
What it gives the team
01Reuse opportunities visible before adding new metadata
02Existing integrations laid out before adding more
03Up-to-date relationship diagrams for any planning conversation
Why it matters
01Cleaner architecture as the org grows
02Decisions made with the full picture in view
03Documentation that keeps up without extra effort
Value that builds over time. The larger and more tangled the org gets, the more painful manual documentation becomes. Data Dictionary removes a recurring job nobody wanted to own.