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.

​
Investigate a component

  1. Search an API name, such as Case.Status, or filter by metadata type.
  2. Select a result. Fields open Where used; other components open All connections.
  3. Switch between Where used (incoming references) and Depends on (outgoing references). Increase the depth to investigate further.
  4. Select a relationship and choose Open source to inspect its supporting excerpt and line.
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 Where used 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. 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 image assets and documented permission/profile filters. 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. 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. Role access and presence settings describe configuration, not a user’s effective access. Usernames are not expanded into user records. Internal navigation routes, runtime topics, Salesforce-only moderation fields 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. 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. Operations on the collection itself, such as checking its size, are not presented as methods on the Salesforce object. An unknown custom-method return type remains an explicit analysis limitation. Expand Trace a path to another component to look for a resolved dependency path, up to six hops. A missing path means none was found within the current index and search budget—not that no relationship can exist.

​
Understand coverage

The Partial index 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. 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.

​
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 initial Connected sample is prepared with each graph publication, so it can open without loading the entire dependency index. It has 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 change does not keep the service awake between visits. Protected package code cannot be recovered by a parser. Binary resources, 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.