A Lightning-native app that turns your Salesforce repository into living, searchable documentation inside Salesforce. It reads the metadata in your Git repo and builds a browsable picture of your entire configuration: objects, fields and relationships; automation including flows, triggers and Apex classes; and security layers including profiles, permission sets, record types, list views and more. ERDs, dependency maps and docs on demand. No spreadsheets, no external tools, no context switching.
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 already committed to your Git repository. It connects to the repo, reads the force-app source, and caches a structured picture of all org configuration into Salesforce. Not just objects, fields, relationships and dependencies, but flows, triggers, Apex classes, profiles, permission sets, record types, list views, custom labels, queues, connected apps and installed packages.
Everything is then surfaced through native Lightning components on a dedicated Data Dictionary app: searchable explorers, ERDs, dependency maps and generated documentation. Rebuild the cache and the picture matches the repo again.
Reads metadata straight from your Git repository, so the documentation reflects what is actually under version control, not someone's recollection of it.
Delivered as a 2GP managed package. LWC viewers run inside Salesforce. No browser extensions, no external apps, no separate login.
Refreshing the picture is a cache rebuild, not a documentation project. The more complex the org, the more that automation is worth.
The GitHub repository is the source. 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.
External and Named Credentials authenticate to GitHub. 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.
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.
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 GitHub 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.
A searchable view of the full metadata surface straight from the repo. Not only objects and fields, but Apex classes and triggers, flows, profiles and permission sets, record types, list views, custom labels, queues, connected apps and installed packages. Filter by type, then read each item's API name, label and key attributes without opening Setup or VS Code.
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.
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.
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.
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.
Guided setup screens connect the GitHub 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.
The same cached picture serves different people in different ways, from the first scoping conversation through to support years later.
Look up an API name, check what depends on a field, and understand existing patterns before writing code, without leaving Salesforce.
Generate ERDs for design reviews, validate relationships, and spot reuse opportunities before adding new objects.
See what already exists when mapping requirements, and avoid asking for fields the org already has.
Use the relationship and field reference to design test scenarios that cover the objects a change actually touches.
A current inventory of configuration to refer to, instead of clicking through Setup to remember how something was built.
Look up field context and relationships when triaging an issue, with fewer escalations to the dev team for "what does this field do?".
A clearer read on complexity for estimates, and faster onboarding for anyone joining the project.
Visual ERDs make the design legible to non-developers, and the knowledge stays in the platform when people move on.