How Metadata and Runtime Telemetry Reveal Which Enterprise System Problems to Fix First

By Karishma Lalwani, Anand Vardhan, and Sanjeevani Bhardwaj.

In our Engineering Energizers Q&A series, we highlight the engineering minds driving innovation across Salesforce. Today, we spotlight Karishma Lalwani, Vice President of Product Management and a Certified Technical Architect at Salesforce, whose team faced a formidable engineering problem: monitoring enterprise orgs handling billions of daily transactions by connecting configuration metadata with constantly changing runtime telemetry scattered across systems with different identities, freshness levels, and access rules. Then, instead of overwhelming customers with every potential issue, the system had to determine what mattered most and prioritize the highest-impact actions requiring the least effort.

Explore how Karishma’s team evolved a static health report into an agentic in-app experience, established approximately 400+ signals across security. process automation, Agentic readiness, customization, data model and other domains, and transformed fragmented enterprise telemetry into deterministic, context-aware next best actions.

What mission drove your team to solve Salesforce org health monitoring at enterprise scale?

Enterprise Salesforce implementations can become so complex that customers lose clarity of their org health and what they should fix first. Products, customizations, integrations, automation, and technical debt accumulate while telemetry becomes scattered across multiple tools. Each tool may identify another set of problems, but without a shared definition of implementation health or a reliable method for prioritizing findings, more information creates decision paralysis instead of clarity.

The mission is to help customers understand how their org is performing and identify the next best action for improving it. Salesforce Health Insights brings product adoption and implementation health monitoring into one experience, helping customers compare their current state with platform-informed standards and prioritize remediation according to criticality and effort. For Sales Cloud adoption, customers can see which available features and licenses they use and where they may be leaving value unrealized.

Initially, the focus is helping customers identify implementation anti-patterns and modernize orgs that have evolved over many years. The north star is proactive: helping customers build scalable, performant, agent-ready implementations and prevent those anti-patterns from returning as their businesses grow.

What made converting a static health report into in-app implementation health monitoring so challenging?

A static PDF could identify problems, but it could not support an ongoing workflow for investigating findings, documenting decisions, guiding remediation, and generating updated insights. Some findings also depend on systems outside Salesforce. A customer might mitigate a risk through an external control, determine that it does not apply to the business, or formally accept it. Without durable dispositions, those findings could repeatedly return as unresolved.

Those limitations shaped how Salesforce Health Insights evolved. The team created an in-app schema that represents findings through standard objects, retains their disposition status, and incorporates those decisions into insights. The experience also distinguishes controls mandated by Salesforce from other important recommendations, enabling customers to track remediation without losing the context behind each finding.

Expanding beyond the original security focus introduced another complication. Product adoption, Process automation, and agentic readiness contain different attributes and remediation patterns. The team designed a common structure that could roll up those findings over time while preserving the distinctions that make each recommendation useful.

Engineering architecture addressing petabytes of telemetry through unified knowledge layer, surfacing insights across pillars and overlaying functionalities for an all-agentic, in-app experience.

How did you connect fragmented metadata and runtime telemetry across billions of daily transactions?

The core engineering challenge was connecting systems that were never designed to behave as one. Configuration metadata provides a point-in-time view of an enterprise system, while runtime telemetry continuously captures its production behavior. Systems such as MuleSoft also have their own identity models, freshness characteristics, and access rules, with no universal shared key connecting every record.

Neither perspective is sufficient alone. Metadata can reveal 1,000 outdated API calls, for example, without showing where they occur, when they run, or whether they affect critical business periods. Runtime telemetry provides that operational context, but only if the system can associate it with the metadata components responsible for the traffic.

Because other teams shared the core metadata pipeline, the team developed an additive architecture instead of rebuilding it. A shared harmonization layer reconciles fragmented datasets, while connector patterns associate those signals with the appropriate metadata. Runtime activity is then mapped to individual components while accounting for traffic, timing, and seasonality.

This architecture maintains a clear boundary between findings computed deterministically from configuration and context supplied by connected systems. It also preserves information about data origin, freshness, and access requirements. The broader north wtar considers whether Data 360 could bring more of this fragmented context into a unified implementation-health monitoring experience.

How did you define implementation-health standards across fundamentally different enterprise orgs?

Customers needed a dependable health baseline even though no two enterprise implementations were identical. A configuration appropriate for one workload, business, or org structure might be unsuitable for another. Generic prescriptions would ignore those differences, but without platform-informed standards, customers had no credible way to evaluate their implementations.

The team contained the initial problem to security and asked what a highly secure Salesforce core implementation should look like. The work began with approximately 100 important signals, then implementation teams and security experts helped expand that foundation to roughly 400. For each signal, the team standardized the metadata rules, threat information, and remediation guidance needed to assess security posture and eliminate anti-patterns. Performance, data models, customizations, and agentic readiness required different criteria. Agentic readiness is broader than preparing an org for Agentforce alone; it identifies the conditions enterprises need to address before their orgs can support agents and other AI tools.

The team combined experience from large Salesforce implementations with Salesforce Well-Architected principles, known system hotspots, and an implementation anti-pattern rubric. The result was a consistent way to define implementation health without assuming that every customer org should be configured identically.

How do you turn implementation-health findings into prioritized remediation across in-app and headless experiences?

Detecting an anti-pattern does not establish its urgency. A technically correct system could still produce a practically useless list of unranked findings, recreating the same decision paralysis it was intended to solve.

The team combines metadata findings with runtime telemetry such as request volume, application CPU, database CPU, call behavior, and peak-business-hour traffic. This operational context reveals which components matter most and allows prioritization of next best actions according to criticality and required effort. Product-adoption recommendations similarly consider what customers have adopted, what they can access, and which outcomes they want to achieve.

The system was also designed with a headless architecture from the beginning. Its schema emits raw JSON so a UI or agent can request implementation-health insights and present them through the customer’s chosen interface. Through an MCP interface, customers can access guidance about security, implementation patterns, and anti-patterns, while the deterministic core helps equivalent conditions produce dependable recommendations. That architecture can extend Salesforce org health monitoring into Slack, where customers could request an overall health summary or their highest-priority security issues and share the guidance with the teammates responsible for remediation.

As the team expands to more customers, self-service artifacts, and interaction surfaces, the goal is to turn complex system signals into clear, trustworthy actions customers can take before today’s anti-patterns become tomorrow’s larger problems, rather than simply to surface more information.

The post How Metadata and Runtime Telemetry Reveal Which Enterprise System Problems to Fix First appeared first on Salesforce Engineering Blog.