Skip to main content
Open Graph, beside Schema, to explore metadata from the Salesforce connections in your current space. Schema shows object relationships; Graph connects code, automation, fields, templates, permissions, and other indexed metadata. Graph and the documentation agent serve complementary tasks: investigate a component’s relationships, then explain and document the change using linked metadata and source context. Generated documentation does not automatically traverse every Graph relationship, and Graph does not turn all connected documents into metadata nodes.

​
Investigate a component

  1. Use Search your Salesforce setup to find a name, such as Case.Status or part of a report name. You can also start with a real item from your org or browse Fields, Emails, Reports, and Automations.
  2. Select a result. Fields answer What uses this?; other items open All connections. Choose What does this use? to explore the other direction.
  3. Explore the Visual map, or switch to Connection list to read the same links as sentences, grouped by the item making each reference.
  4. Select a connection to see why the two items are linked. Code is optional: expand View source details (technical) and choose Open source when you need its supporting excerpt and line.
How do I read the graph? explains the dots, arrows, and limits. Start over returns to the simple search. On a phone, search is available directly on the page; close the details panel to give the map or list more room. The direction buttons count directly connected components in the index. The canvas count describes only the currently displayed, bounded view. Pan, zoom, fit, and drag nodes to explore. Copy component link gives you a shareable entry point; recipients still need access to the same workspace and connection.

​
Follow evidence across metadata

Supported static references include Apex calls and field access, Flow reads and writes, layout field references, permission grants, Lightning imports, and email-template merge fields. For example, an email template using a custom field can appear in that field’s What uses this? view. Paths and celebration animations link to their configured objects, fields and record types. Lead-conversion mappings connect each input field to its own output field; unrelated mapping pairs are not treated as a dependency path. The explorer also follows supported role hierarchy, queue membership and routing, service-channel fields, profile policies, topic settings and moderation criteria. Experience Cloud sites connect to their configured email templates, profiles, Visualforce pages and supported assets. Navigation menus link to their declared site or template, Salesforce objects, verified list views and tile images. Moderation rules, keyword lists and user criteria link back to their site. This makes it possible to investigate a supported site → email template → field path, not just a template’s direct references. Sites also link to configured headless registration and password-reset email templates. Audience definitions retain their site context and supported targeting criteria. Only documented, independently verified metadata targets create links; audience membership and users’ runtime behavior are not inferred. Translations link to verified objects, fields and other supported metadata members; translated labels and picklist text do not become code dependencies. Lightning themes connect to branding sets and their verified image assets, so you can follow a theme → branding → asset path. Supported notification actions also link to their configured Apex class. Field-restriction rules link to their configured field sets and supported field expressions. Prompts link to their verified Salesforce application, image assets and documented permission/profile filters. Application dependencies support reverse usages, paths and source evidence. Missing targets, conflicting application settings and unknown experience values keep coverage incomplete. Notification settings keep each notification’s application references separate; a disabled setting is still configuration, not proof that a notification will be delivered. Data-cleaning rules show the Salesforce fields they read and write. Their virtual data-service fields stay separate from real Salesforce fields, and the explorer does not invent paths through unrelated mappings. Provider notification names, excluded applications, internal prompt context and unindexed virtual schemas remain explicit limitations. Group definitions, campaign-influence options and trusted-site policies can legitimately have no outgoing metadata links; group membership and effective access are not inferred from a group definition. External-client settings link back to their application. Supported references also include authentication handlers, custom OAuth scopes, verified permission-set and signing-certificate identities, and qualified fields used in custom attributes. App menus can link to explicitly named applications, sites and tabs, but their undocumented behavior remains partial. Standard OAuth scope names are capabilities, not metadata dependencies or proof of effective access. Supported settings now link to active custom themes, identity certificates, searchable objects, territory-assignment Apex handlers and forecast types. Home-page layouts link to custom components; standard widgets remain platform items. Forecast columns use exact field paths or verified identities, not display labels or guessed field names. Unmapped columns and unfamiliar settings remain partial. Supported Case settings include configured templates, email handlers, queues, flows and record types. Default picklist values remain values of their explicitly named fields, not components guessed from their labels. Known boolean, numeric and enumerated settings can be fully understood without outgoing links; unsupported nested settings and missing targets remain gaps. Address settings treat country and state values as configuration, not field dependencies. Business Hours settings include their named schedules and separate holiday entries; supported holiday references link to the schedule they actually name, without paths through unrelated holidays. Security settings can link to a configured welcome-email template when its identity is independently verified. Unknown properties, unsupported values and missing targets remain gaps. These views describe configuration; they do not calculate operating hours, change security settings or evaluate a user’s effective access. CMS content-type definitions include their declared fields, while managed topics retain site ownership and supported parent-topic relationships. These describe metadata configuration, not the CMS content records, actual topic assignments or users. A definition with no outgoing dependency can be fully understood without inventing a link. An asset’s metadata can be understood while its file contents remain unanalyzed. That limitation stays visible, even when the asset has proven incoming usages. Unverified translation aliases, unfamiliar branding properties and ambiguous identities remain partial instead of being matched by similar names. Value sets and remote-site settings may legitimately have no outgoing metadata links. Supported CSV static resources are checked against both their declared file type and their actual table contents. The graph retains evidence for both sources; malformed, oversized or mismatched files remain incomplete. Table values are data, not automatic field dependencies. A CSV can therefore have proven incoming usages without outgoing metadata links. Supported PNG and JPEG Documents, static resources and single-version ContentAssets are validated against their original file contents and metadata. ContentAssets also require a valid single-version definition and a matching file format; retrieving a file alone does not make it fully analyzed. A Document links to its independently discovered folder; supported folder sharing can link to declared groups and roles. Image pixels, filenames and embedded text do not become guessed field references. Missing files, unsupported formats, invalid or oversized images and unknown settings remain incomplete. Multiple or zipped asset versions, archives, JavaScript and site-file payload semantics are not covered. Users named in sharing settings are not looked up. Open CTI call centers can link to their configured primary and standby Visualforce adapters. Matching settings retain their source evidence; conflicting settings, unsupported options and missing targets keep coverage incomplete. Package pages outside your selected scope remain unresolved. These links describe configuration, not proof that an adapter ran. External adapter URLs are not treated as local Salesforce pages, and no users or business records are read. Moderation rules distinguish ordinary fields from Salesforce’s Metadata API-only RawBody and RawCommentBody content selectors. Those selectors link to the moderated object, retaining the exact selector in the supporting evidence. They do not create guessed usages of Body or CommentBody. Disabled rules still describe configuration, not proof that content was moderated. Role access and presence settings describe configuration, not a user’s effective access. User IDs and usernames are not expanded into user records, even when a queue, site or email-notification setting references them. Those identity gaps remain visible under metadata-only indexing. Internal navigation routes, runtime topics and unverified console-component identities remain explicit gaps. Unknown metadata properties are reported as partial coverage, not guessed links. Labels, keywords, standard tabs and external URLs do not become invented dependencies. The catalog also includes available compound-field members, such as a contact’s first name and individual address fields. Salesforce’s live schema supplies standard fields, lookup targets and named child relationships, so supported field paths can be followed across objects. References are matched to declarations from your Salesforce connection, not guessed field names. Fields missing from an object’s source can also use Salesforce’s field-definition metadata. This adds verified field-to-object and compound-member links, plus lookup targets that Salesforce explicitly names. Newly discovered targets are checked against available object schema in the same sync. An ownership link does not create a dependency path through unrelated sibling fields. This reads schema only—not users, record-access results or business records. Missing lookup targets, unavailable formulas and incomplete polymorphic or compound definitions remain partial. A display type such as “Lookup” is not enough to invent its target. Complete retrieval and complete semantic analysis are separate checks. Some dynamic Apex references can be resolved when their values are provable constants. Values supplied by users, changed by runtime branches or computed outside the analyzed code remain unproven. Nested-folder reports and dashboards keep stable component links even when Salesforce returns a longer folder path. References use verified identities and full paths; similarly named reports in different folders are not guessed to be the same component. Report field aliases are matched using the column definitions Salesforce exposes for that report type. Only fields actually referenced in a report create usages—not every field available to its report type. This reads reporting metadata without executing reports or retrieving their result rows. Inaccessible report definitions and unsupported calculated columns remain gaps. Profiles can also lead to their backing permission sets and the direct object, field and setup-component access Salesforce exposes. This supplements permission entries omitted from a Profile source retrieval. Disabled permissions are shown as configuration references, not access grants. A broad “View All Fields” permission stays an object-level fact; the graph does not invent a separate grant for every field. These links explain permission configuration, not a user’s effective access. Assignments, permission-set groups, muting, licenses and implicit access still need separate evaluation. Missing or excluded targets remain unresolved. Typed Apex lists and maps retain their field references when code accesses an element, including nested collections. The graph also follows supported method-return chains and declared class properties across indexed files. A returned Salesforce object can establish a real field usage; an ordinary Apex data-container property links to its declaring class, not an invented Salesforce field. Supported platform operations, such as formatting a returned date, are not presented as customer metadata dependencies. Return-type links include the supporting declarations in their source evidence and are re-evaluated when those declarations change or leave scope. Unknown return types, ambiguous overloads, unsupported reflection and runtime-dependent values remain explicit limitations. Supported static schema reflection also creates usages of the actual Salesforce object and record type. A constant developer-name selector can link its object-scoped record type; a constant record-type ID needs an independently known metadata identity. Display labels are not treated as developer names. Runtime selectors, ambiguous identities and unsupported reflection stay incomplete. This does not read User or business records or execute Apex. Expand More ways to explore to adjust the number of steps or trace a path to another item, up to six steps. Path discovery searches beyond the small display sample, so a busy component does not hide a reachable target merely by filling the canvas. Search work and displayed paths are still bounded. A missing path means none was found within the current index and search budget—not that no relationship can exist.

​
Understand coverage

The Some connections may be missing disclosure shows coverage by component type: The number of types with gaps is not a percentage of missing dependencies. A type is counted if even one component has partial, structural or catalog-only coverage. Expand the disclosure to see the breakdown; a known component can still have proven links while other analysis remains incomplete. A catalog-only field can still have proven incoming usages from a Flow, layout, or template. Source previews are withheld when the retrieved source has changed since indexing, so old line numbers are not presented as current evidence. External OAuth and connected-app source previews redact credential and certificate contents while keeping the original reference lines. A sensitive source that cannot be safely parsed is withheld. This does not claim to detect every secret that might be embedded in arbitrary code.
This is static analysis, not a runtime trace or a safe-delete recommendation. Dynamic code, inaccessible managed-package source, excluded metadata, and incomplete retrieval can hide dependencies. Support for a component’s identity does not mean complete semantic support for every metadata type.

​
Keep the graph current

Use Fetch latest metadata on the Salesforce connection, then refresh Graph. Dependency-bearing source is retrieved ahead of large content assets, and useful snapshots become available as indexing progresses. Component-type and managed-package ingest settings also scope the graph. With customer-owned metadata selected, package-owned fields stay excluded even when declared inside an otherwise in-scope object. A customer component’s reference to an excluded target can remain visible as unresolved evidence; that does not include the package’s source or expand your ingest scope. Unchanged, successfully verified source can skip another download. Partial or omitted source stays eligible for retry. A successful retrieval request does not mean every requested component was returned; missing-source and permission limitations remain coverage gaps, even when older source is available. Report-type definitions are shared across reports and reused for up to one day, unless a newer recorded modification or a full metadata refresh requires another check. Large column-definition dictionaries stay out of interactive graph responses. Successfully captured profile-backed permission records use the same one-day refresh policy. An unsuccessful refresh preserves the earlier capture but marks its evidence as no longer verified current. It does not turn a limited Profile retrieval into complete coverage. Supplemental field definitions also reuse successfully verified captures for up to one day, unless a newer recorded modification or full refresh requires another check. A failed refresh preserves the old capture but withholds it as current source evidence.

​
From Salesforce to a useful graph

  1. LivingContext discovers the metadata types and components your connection can access.
  2. It retrieves source and reads the actual object schema, keeping the two kinds of evidence distinguishable.
  3. Static analysis extracts declarations and references, then matches them across components.
  4. A new snapshot replaces the previous one only after a successful build. Unchanged source can reuse its previous analysis.
  5. Graph loads a bounded neighborhood when you explore. Shareable component links and source excerpts keep an investigation tied to evidence.
Indexed lookups speed up repeated exploration without downloading the whole organization’s graph to your browser. Access and the latest published snapshot are checked on every request. If the graph is temporarily busy, retry shortly—this does not mean the component has no dependencies. Compact snapshots reduce transfer and memory costs while preserving relationship and source evidence. Static graph exploration does not need an AI model to start. The first exploration after an idle period can still take longer than subsequent queries; smaller snapshots are not a guarantee of instant startup. The starting examples and optional Browse sample map use a small selection prepared with each graph publication, without loading the entire dependency index. They have the same access checks, relationships and coverage information as that snapshot. The first deeper exploration can still take longer while the full index loads; this does not keep the service awake between visits. Protected package code cannot be recovered by a parser. Unsupported binary formats, manifest-limited Profiles, unsupported reference syntax and runtime-only values also remain coverage limits. A component with no proven link is still discoverable; the graph does not add a relationship merely to connect every node.