IT has long been at the center of enterprise transformation. What is often underappreciated, however, is that IT organizations must continuously transform themselves in parallel with the business. At times, it can feel like changing the tires on a moving car—entirely possible, but requiring clarity of vision, disciplined execution, and strong leadership alignment.

The following are core strategies I’ve consistently applied to deliver results at scale in high-growth environments:

• Product vs. Project: Shift from project-based delivery to a product-oriented operating model.

• Agile and DevOps: Combine modern delivery practices with engineering discipline and automation.

• Resource Strategy: Evolve workforce models to support speed, quality, and long-term capability building.

Let’s explore each in more detail.

Product vs. Project

This is not about whether your company sells products or services—it is about how IT delivers value.

Traditional project-based models are designed around fixed scope, timelines, and budgets. Success is often measured by whether a project is delivered on time and within cost constraints. However, this model does not inherently ensure that the right outcomes are achieved or that long-term business value is created. It can also lead to fragmented execution, limited knowledge retention, and slower delivery over time.

A product-oriented model shifts the focus to sustained ownership of business capabilities. Persistent teams are aligned to products or services, funded over longer horizons, and accountable for outcomes rather than outputs. These teams develop deep domain expertise and are better positioned to continuously evolve their products in alignment with business needs.

From an organizational standpoint, this model also aligns with how high-performing teams operate. Drawing from Tuckman’s stages of development—forming, storming, norming, performing, and adjourning—long-lived product teams spend more time in the “performing” stage. In contrast, project-based teams often disband just as they reach peak effectiveness, resulting in lost momentum and institutional knowledge.

While transitioning to a product-centric model is not trivial, it sends a clear signal to stakeholders: IT is committed to long-term capability building, continuous improvement, and delivering meaningful business outcomes.

Agile and DevOps

Agile and DevOps are often discussed independently, but their true value is realized when implemented together.

Agile methodologies—such as Scrum, Kanban, and Extreme Programming—enable teams to deliver iteratively and respond quickly to changing requirements. DevOps, on the other hand, represents a cultural and operational shift that integrates development and operations through automation, continuous integration, and continuous delivery (CI/CD).

In practice, product-aligned teams should have the flexibility to adopt Agile methodologies that best suit their needs. For teams using Scrum, a two-week sprint cadence is often effective in establishing predictable delivery cycles and improving cross-functional alignment.

However, Agile practices alone are insufficient without the supporting engineering discipline of DevOps. Automation across the software delivery lifecycle—from code integration to production deployment—is essential to achieving both speed and quality. This allows engineers to focus on solving business problems rather than managing manual processes.

From an operating model perspective, embedding teams with DevOps personnel, as well as establishing DevOps as a shared service, can drive consistency in tooling, standards, and practices across the organization, while also creating a clear career path for engineering talent.

The primary challenge is not technical—it is cultural. DevOps requires breaking down traditional silos and redefining roles and responsibilities. Resistance is natural. Success depends on leadership alignment, clear communication, and a sustained commitment to change. When done effectively, Agile and DevOps together enable organizations to deliver faster, more reliably, and with greater business impact.

Resource Strategy

Transforming delivery models requires more than new processes—it requires investment in people.

As organizations evolve toward product-based, Agile, and DevOps-driven models, skill gaps often emerge. At the same time, the business cannot afford a decline in delivery quality during the transition. Maintaining trust with stakeholders is paramount.

This is where a well-defined resource strategy, including strategic partnerships, becomes critical.

Staff Augmentation

A shift to Agile and product-based delivery necessitates a move away from traditional managed services models toward staff augmentation. Managed services often externalize critical expertise, limiting an organization’s ability to build internal capability and reducing long-term agility.

In contrast, staff augmentation integrates external talent directly into internal teams, enhancing capacity while preserving ownership and accountability. This model is far better aligned to Agile principles and supports the development of high-performing, cross-functional teams.

Attempting to apply managed services constructs within an Agile model is a common failure pattern. Organizations must align their sourcing strategy with their delivery model to succeed.

Recruiting and Hiring

It’s important to ensure that both internal and augmented teams meet consistent standards of excellence. This requires alignment on technical competencies, engineering practices, and cultural expectations. I strongly advocate for applying the same hiring rigor to contingent talent as to full-time employees, including technical assessments and evaluation of soft skills.

Learning & Development

One of the most valuable attributes to assess is the ability to both teach and learn. High-performing teams create a two-way exchange of knowledge: external talent brings new skills and perspectives, while internal teams provide institutional knowledge and context. This dynamic fosters a culture of continuous learning and becomes a meaningful competitive advantage.

Timezone Proximity

Team structure must also account for collaboration dynamics. While fully co-located teams may not always be practical, effective Agile delivery requires sufficient overlap for real-time communication. In my experience, maintaining a 2–3 hour overlap with the core business timezone strikes the right balance. This enables collaboration without introducing the inefficiencies and burnout associated with highly distributed, asynchronous models.

On-Call and Incident Response

A mature DevOps model requires shared accountability for production systems. Teams that build services must also support them. Establishing clear on-call and incident response processes ensures system reliability while reinforcing ownership. This expectation must apply to both full-time and augmented team members and should be clearly defined from the outset of any partnership.

Building Cohesive Teams

Sustaining high performance across distributed teams requires intentional effort. Strong relationships do not emerge by default—they must be cultivated.

Creating opportunities for teams to connect—whether through regular social interactions, volunteering initiatives, periodic in-person collaboration, or recognition programs—strengthens trust and reinforces a shared sense of purpose. These investments are not peripheral; they are foundational to maintaining teams in a high-performing state.

Final Perspective

Enabling IT to support a fast-growing enterprise while building a scalable, durable delivery organization requires deliberate choices. It demands a shift to product-based thinking, the integration of Agile and DevOps practices, and a resource strategy that prioritizes capability over convenience.

This transformation is not without challenges. It requires sustained commitment, cultural change, and strong leadership. However, when executed effectively, it positions IT not as a support function, but as a strategic driver of business growth, innovation, and long-term competitive advantage.

This presentation highlights how Salesforce has approached data integration within the context of a high-growth, fast-paced technology company—balancing the need for agility with the discipline required to build a scalable and resilient foundation.

Title: Connecting the Customer Success Platform: How Salesforce Approaches Integration

Description: As a $5B organization growing at 30% year over year, Salesforce prioritizes agility and scalability as core operating principles. This session explores how introducing an “agility layer” enables more streamlined employee lifecycle management—driving improvements in productivity, customer satisfaction, and overall cost efficiency.

Video Recording: https://www.salesforce.com/video/193056/

My team’s vision is clear: connect the business to trusted data—securely, reliably, and in real time—so that teams can access what they need, when and where they need it. This is foundational to becoming a truly data-driven enterprise. This document outlines how we achieve that vision through a modern, scalable integration architecture.

Target End State

The target end state represents a modernized data integration platform designed to deliver Data-as-a-Service (DaaS) at enterprise scale. At its core, data integration is about the efficient and reliable movement of data between systems. However, to truly enable business agility, this capability must evolve into a platform that delivers data as a consumable service.

The broader industry direction reinforces this approach: real-time data access, REST-based APIs, and self-service consumption models are rapidly becoming the standard. By aligning to these principles, we position the organization to leverage existing standards, adopt emerging ones such as OData, and unlock new opportunities through faster, more intelligent use of data.

The reference architecture illustrates the end-to-end lifecycle of data—from publisher to consumer—providing a holistic view of how data flows across the enterprise. Understanding this lifecycle is critical to designing a platform that is both scalable and resilient.

ESB & SOA

At the foundation of the platform is the ESB and SOA layer, which serves as the operational backbone of the integration architecture. This layer addresses many of the limitations inherent in point-to-point models by centralizing connectivity, enabling real-time data routing, supporting data aggregation, and decoupling systems.

From a leadership perspective, this is where standardization and reuse begin to take hold. Rather than building bespoke integrations for each use case, this layer establishes a common framework for how systems communicate—reducing complexity and enabling scale.

Adaptors

Within this architecture, ESB adapters play a critical role. Each adapter is designed with a single responsibility—either interfacing with a source system or a target system—while encapsulating the logic required for that interaction.

For example, retrieving employee data from Workday would involve a source adapter responsible for querying the system, transforming the data into a Canonical Data Model (CDM), and publishing it to the Message Exchange. Target adapters then independently consume that data and deliver it to downstream systems.

This modular approach localizes change, reduces duplication, and significantly improves maintainability across the integration landscape.

Canonical Data Model

The Canonical Data Model (CDM) is a cornerstone of the architecture. Its primary purpose is to decouple source and target systems by introducing a standardized data representation across the enterprise.

Without a CDM, integrations become tightly coupled, requiring direct mappings between systems. This creates fragility and high cost when systems change. For example, a simple attribute change in a source system can cascade into widespread integration rework.

By contrast, a CDM introduces an intermediary layer. Source systems map to the canonical model, and target systems consume from it. This isolates change and dramatically reduces the impact of system migrations or upgrades. It is a foundational capability for achieving true enterprise agility.

Message Exchange

The Message Exchange (ME) provides real-time data distribution across the platform. It acts as a broker, enabling source systems to publish events and target systems to subscribe to them.

This model introduces several key advantages. First, it supports a publish-and-subscribe pattern, allowing new consumers to be added without modifying existing integrations. Second, it ensures reliable message delivery. If a downstream system is unavailable, messages are queued and retried, or routed for manual intervention if necessary.

This is a significant advancement over P2P architectures, where failures often require reprocessing entire datasets. The ME enables resilience, scalability, and operational efficiency in how data flows across the enterprise.

Taken together, these components—adapters, canonical data model, and message exchange—form the foundation of a loosely coupled integration architecture. This is what enables flexibility, reduces cost, and allows the enterprise to evolve without constant rework.

However, while SOA provides a strong foundation, it is not sufficient on its own to meet the demands of modern digital businesses. To truly unlock agility, data must be made directly accessible to those who need it.

APIs & API Management

APIs are the mechanism through which data becomes accessible, consumable, and actionable. They extend the value of the integration platform by placing data directly into the hands of developers, applications, and ultimately, the business.

From a strategic standpoint, APIs enable both operational efficiency and new business models. Internally, they accelerate development and simplify access to complex data. Externally, they create opportunities to monetize data and expand digital ecosystems.

Within the enterprise, APIs typically fall into three categories:

1. Aggregation APIs: Simplify access by combining data from multiple systems into a single, optimized interface. For example, a Worker API that aggregates data from Workday, Fieldglass, and Supportforce into a unified view.

2. Internal Application APIs: Expose functionality from internally developed systems, enabling reuse and service-oriented design.

3. Packaged APIs: Provided by third-party platforms to expose application capabilities.

As the number of APIs grows, API management becomes essential to ensure scalability, security, and governance.

Security

Exposing data through APIs introduces risk, making security a top priority. API management platforms provide robust mechanisms such as OAuth2 for authentication and authorization, along with protections against threats such as denial-of-service attacks and payload-based vulnerabilities.

Equally important is the ability to quickly revoke access if a compromise occurs—ensuring that risk can be contained in real time.

Policies

API policies enable control over how APIs are consumed. Capabilities such as rate limiting, traffic management, and content-based routing ensure consistent performance and protect backend systems from overload.

These controls are essential to maintaining reliability as adoption scales.

Proxies

API proxies provide a layer of abstraction between consumers and backend systems. This decoupling allows backend services to evolve without impacting API consumers, enabling faster innovation and reducing dependency-related risk.

Analytics

APIs introduce a new dimension of visibility. With analytics, organizations can monitor usage patterns, understand demand, and enforce service-level agreements. This data-driven insight is critical for managing APIs as products and ensuring they deliver measurable value.

Self-Service API Portal

The final step in delivering Data-as-a-Service is enabling self-service access through an API portal. This provides a centralized interface for discovering, accessing, and managing APIs.

Through the portal, developers can explore available APIs, review documentation, request access, and begin integration quickly—without friction or dependency on centralized teams. This model significantly accelerates development cycles and empowers innovation at scale.

Consider a simple example. A developer building a mobile employee directory needs access to worker data. Rather than integrating with multiple systems and managing disparate data models, the developer can discover a unified Worker API through the portal, request access, and begin development immediately. The complexity of aggregation, transformation, and governance is abstracted away—allowing the developer to focus on delivering business value.

This is the essence of Data-as-a-Service: simplifying access, increasing speed, and enabling the organization to fully leverage its data assets.

The diagram below reflects the current state of point-to-point (P2P) integrations within Salesforce at the time of this writing. It represents the underlying integration fabric supporting a multi-billion-dollar business—an architecture that, while functional, highlights the systemic risks of incremental, uncoordinated integration strategies.

P2P integrations can be expedient to implement, but they quickly become unmanageable and costly. When environments are small, P2P integrations appear to be a lightweight and efficient way to connect systems. However, as the organization scales, this approach does not remain sustainable. What begins as simplicity evolves into fragility—creating an integration landscape that is brittle, difficult to maintain, and increasingly misaligned with evolving business needs.

No organization sets out to create integration complexity. Rather, P2P architectures emerge organically over time, often driven by shifting business priorities and the absence of a cohesive, enterprise-wide integration strategy such as SOA or API-led design. Delivery teams, under pressure to meet deadlines, frequently prioritize immediate outcomes over long-term architectural integrity. In many cases, more sustainable solutions are deferred due to perceived cost, complexity, or risk. It often takes a significant disruption—escalating IT costs, widespread system instability, or a critical failure triggered by a single change—for organizations to fully recognize the extent of the problem.

The Hidden Cost of P2P

The limitations of P2P integration are not always immediately visible in smaller environments. However, the number of connections required to integrate systems grows exponentially as new components are added. This becomes particularly problematic for organizations that depend on an expanding ecosystem of internal systems and external partners.

For example, integrating three systems requires only three connections (assuming unidirectional flows). Expanding to five systems increases this to ten connections. At scale, the number of required connections follows the formula N(N-1)/2, where N represents the number of systems. A network of ten systems requires 45 = 10(10–1)/2 distinct connections—each one introducing additional development, testing, and maintenance overhead. The P2P cost model increases exponentially as the size of the network increases linearly, as illustrated by the cost curve in the diagram below.

Every connection represents time and resources diverted away from innovation and net-new business capabilities. In practice, many organizations lack the capacity to adequately maintain or modernize these integrations. The result is often a complex, poorly documented web of dependencies that becomes one of the most mission-critical—and fragile—components of the enterprise architecture.

At a project level, P2P integration can appear cost-effective. This aligns with how IT has traditionally measured success—optimizing for immediate delivery within constrained budgets. However, at the enterprise level, the cost dynamics shift dramatically. Each additional P2P connection contributes to a non-linear increase in total cost of ownership. While the value of the network grows linearly, the associated costs scale exponentially, creating a widening gap between investment and return. This dynamic underscores a fundamental challenge in traditional IT funding models.

Security Concerns

Beyond cost, P2P architectures introduce significant security and governance risks. In the absence of centralized control, it becomes increasingly difficult to track data access, enforce compliance, and respond to potential breaches. As multiple teams independently establish direct integrations across cloud and on-premise systems, visibility into data access patterns diminishes.

This fragmentation often leads to the proliferation of API user accounts and credentials, increasing the organization’s attack surface. From a risk management perspective, each additional access point represents potential exposure.

Additionally, a lack of coordination can result in conflicting data interactions. For example, in one case involving Workday Market Segment data, multiple teams unknowingly updated the same data attribute, leading to data overwrites, confusion, and rework. This issue persisted for years, driving productivity losses and introducing avoidable business risk—illustrating how integration architecture directly impacts data integrity and operational trust.

Budget Constraints

From a funding perspective, P2P integration reinforces inefficiencies. Each new application—whether mobile, web, or enterprise—requires access to data, and each project typically allocates budget to build or extend integrations. This project-level (microeconomic) approach diverts investment away from differentiated business functionality and toward redundant integration efforts.

At scale, this results in a significant misallocation of resources. Rather than repeatedly funding bespoke integrations, organizations should consider investing in shared, reusable data access capabilities that reduce duplication and improve long-term efficiency.

Limited Capabilities

Another consequence of P2P integration is the embedding of business logic within integration code. Under delivery pressure, teams often hard-code business rules alongside data transformations. While expedient, this approach creates long-term challenges by obscuring business logic and increasing maintenance complexity.

A representative example involved new hire processing within Workday. Critical business rules embedded within integrations were not visible to application development teams, limiting their ability to deliver new functionality effectively. A more sustainable model separates business logic from integration layers, enabling greater transparency, flexibility, and speed of change.

Mergers & Acquisitions

Salesforce’s growth strategy includes frequent acquisitions, often integrating acquired companies as distinct business units. This model increases the importance of scalable integration capabilities, as both front- and back-office systems must be connected efficiently.

In some cases, integration may involve straightforward data migration. More often, however, acquired systems must be integrated into an existing ecosystem. In a P2P architecture, this process becomes time-consuming, costly, and operationally complex—limiting the organization’s ability to rapidly realize value from M&A activity.

Lost Opportunities

Over time, P2P environments become increasingly difficult to support. As complexity grows, teams become more risk-averse, hesitant to implement changes due to uncertain downstream impacts. At this stage, IT transitions from an enabler of business innovation to a constraint on it.

The consequences are tangible: slower time-to-market, reduced agility, and missed revenue opportunities. In a competitive landscape, these delays can have material business impact.

Supportability & Scalability

At enterprise scale, the limitations of P2P integration become unmistakable. These architectures are inherently difficult to support and do not scale effectively.

A clear example comes from an initiative to upgrade Oracle Financials from 10g to R12. At the time, the IT landscape included approximately 55 P2P integrations. Introducing just four new data fields—Business Unit, Market Segment, Company, and Primary Coverage Country—required updates across a vast network of connections. Applying the N(N-1)/2 model, this resulted in 1,485 integration touchpoints, over a year of development effort, and approximately $1 million in cost—simply to accommodate a relatively modest change.

This example underscores a broader reality: without a scalable integration strategy, even small changes can carry disproportionate cost and risk.

As you evaluate data and integration requirements, it is critical to consider both strategic and tactical dimensions—the value delivered is directly correlated to this perspective. The Data Integration Maturity Matrix referenced below illustrates how various integration activities contribute to the organization’s overall maturity. Complementing this, the Technology Decision Matrix is intended to guide teams toward IT-supported technologies aligned to their needs. The following sections outline each integration activity, including business and technical drivers, key considerations, and representative use cases, along with recommended technologies.

Data Virtualization

Data virtualization enables applications to access and manipulate data without requiring knowledge of its physical location, format, or underlying structure. From a CIO perspective, this approach can accelerate access to distributed data while minimizing data movement.

Business Drivers

• Integrated view of information through a unified interface

• Improved user productivity and reduction in manual errors

Technical Drivers

• UI-level integration across disparate systems

• Consistency without the need for replication or synchronization

• Unified data access via technologies such as the SFDC OData XDS Connector

Considerations

• Requires data sources to be exposed as OData API feeds

• Limited to presentation-layer integration; does not support transformation or orchestration for higher-value use cases

• Typically point-to-point and tightly coupled to source systems

• Salesforce Connect (as of FY15Q4) supports read-only access to external data sources

Use Case Examples

• Mobile and web applications accessing distributed data sources

• Cloud-based application logic leveraging externalized data

• Salesforce accessing legacy systems without data movement

• BI tools querying multiple heterogeneous data sources

Recommended IT Technology

• MuleSoft

• Jitterbit

Data Load

Data load refers to the bulk movement and transformation of data between systems, commonly associated with data warehousing and migration scenarios.

Business Drivers

• One-time system cutovers and migrations

• Loading cleansed customer, lead, or operational data

Technical Drivers

• High-volume bulk data movement

• Support for complex data transformations

• Targeted solutions for specific, well-defined use cases

Considerations

• May require multiple iterations to achieve desired outcomes

• Latency and processing windows must align with business requirements

• Performance optimization often requires specialized data loading logic

• Typically results in tightly coupled architectures with higher long-term maintenance costs

Use Case Examples

• Bulk loading into data warehouses

• Database-to-database migration

• Replicating large datasets across environments

• Supporting backup, disaster recovery, or failover strategies

• Loading data into cloud-based platforms

Recommended IT Technology

• MuleSoft

• Informatica

• Jitterbit

• Salesforce Import Wizard

Data Synchronization

Data synchronization ensures consistency across systems by continuously aligning data between source and target environments over time.

Business Drivers

• Creation of a unified customer view

• Consistent cross-channel customer experiences

• Improved decision-making and operational performance

Technical Drivers

• Bi-directional or multi-system data consistency

• Real-time or scheduled synchronization capabilities

• Maintenance of data integrity across platforms

Considerations

• Latency requirements (real-time vs. batch) must align with business needs

• Increasing data volumes can impact scalability and performance

• Data reconciliation complexity varies by implementation

• Data profiling is recommended before synchronization

• Conflict resolution strategies must be defined (e.g., system of record, ownership rules)

Use Case Examples

• Ongoing data warehousing for analytics

• Synchronization across CRM, ERP, and other enterprise platforms

Recommended IT Technology

• MuleSoft

• Informatica

• Jitterbit

Process Automation

Process automation integrates systems and orchestrates workflows to streamline operations, reduce costs, and improve consistency across the enterprise.

Business Drivers

• Automation of cross-functional business processes

• Enhanced customer experiences through real-time responsiveness

• Reduction in operational costs

• Improved compliance and risk management

Technical Drivers

• Fragmented data and workflows across departments

• Orchestration of processes across multiple application silos

• Alignment with internal service-level agreements (SLAs)

Considerations

• Availability of APIs for systems and data access

• Data ownership, location, and accessibility

• Real-time processing requirements

Use Case Examples

• New hire onboarding automation

• Quote-to-cash process orchestration

• Automated incident and outage management

Recommended IT Technology

• MuleSoft

• Informatica

Shared Services

Shared services represent a service-oriented approach where reusable components and capabilities are made available across the enterprise to drive consistency and efficiency.

Business Drivers

• Accelerated time-to-market for products and initiatives

• Increased ability to innovate and respond to market opportunities

• Reduced operational costs through reuse and standardization

Technical Drivers

• Application decoupling and code reuse

• Simplified maintenance of large-scale integration environments

• Standardized data definitions and formats

Considerations

• Requires strong executive sponsorship to drive adoption of a service-oriented architecture (SOA)

• Necessitates a centralized service layer acting as an internal provider

• Requires upfront investment to achieve long-term returns

Use Case Examples

• Reliable delivery of business-critical data events (e.g., customer orders)

• Reduced dependency between source and consuming systems

• Reuse of services across new and existing applications

Recommended IT Technology

• MuleSoft

APIs

APIs define standardized interfaces that enable systems to communicate while decoupling implementation from consumption. From a strategic standpoint, APIs are foundational to digital business models and ecosystem integration.

Business Drivers

• Enabling mobility and connected digital experiences

• Monetizing data and creating new revenue streams

• Driving operational efficiency across the enterprise

Technical Drivers

• Standardized and secure access to enterprise and application data

• Ability to monitor, govern, and audit usage

• Decoupling of consumers from backend systems

• Increased visibility into data definitions and quality

Considerations

• Broader API adoption increases ROI and lowers the marginal cost of integration

• Requires skilled resources for design, implementation, and lifecycle management

• Must be designed with a clear audience and use case in mind

• Requires lifecycle governance beyond initial deployment

Use Case Examples

• Real-time data access for mobile and web applications

• Process automation through the orchestration of multiple APIs

Recommended IT Technology

• MuleSoft

Technology Decision Matrix

Selecting the appropriate integration technology can be complex, particularly in a rapidly evolving technology landscape. The Technology Decision Matrix is designed to simplify this process by aligning use cases with recommended platforms. However, it should be used in conjunction with guidance from the Enterprise Architecture Review Board (EARB), as specific business and technical requirements will ultimately determine the best fit.

This framework is intentionally adaptable and should evolve alongside the organization’s capabilities and technology portfolio. As CIOs, our role is to ensure that such frameworks not only guide decision-making but also promote consistency, scalability, and long-term architectural integrity across the enterprise.

As organizations accelerate their adoption of cloud technologies, the ability to seamlessly integrate and expose data across both cloud and on-premise environments is no longer a technical aspiration—it is an operational imperative. Enterprises that lead in defining, integrating, and democratizing access to their data will differentiate themselves in increasingly competitive markets. This advantage manifests in two critical dimensions: 1/ enabling real-time, structured data access to power business processes, applications, and automation; and 2/ unlocking the full value of data through advanced analytics, reporting, and predictive intelligence that informs decision-making at scale.

One slide from the presentation stood out as a blueprint for a long-term enterprise data strategy. At its core is a concept that I believe CIOs must champion: Data-as-a-Service (DaaS). To truly empower the business, accelerate growth, and foster a culture of innovation, enterprise data must be elevated to a managed, strategic service. This requires IT leadership to drive a data-centric operating model—one that encompasses governance, standardization, quality, enrichment, aggregation, and transport. While all of these components must function cohesively, the data transport strategy is often the catalyst that unlocks progress. Establishing scalable, reliable data transport layers requires intentional investment, specialized expertise, and early prioritization.

Budget & Priorities

Within any enterprise, resource allocation reflects strategic priorities. Marketing invests in customer engagement platforms, finance modernizes reporting for greater transparency, and IT drives automation to improve efficiency and reduce cost. While these initiatives may appear distinct, they share a common dependency: timely, accurate, and accessible data.

Increasingly, business units are making independent technology decisions—driven by greater technical fluency and the accessibility of cloud solutions. This trend underscores a critical leadership challenge: ensuring that decentralization of technology does not result in fragmentation of data. Regardless of where applications are deployed or who owns them, enterprise data remains the connective tissue. Without a coherent data strategy, organizations risk undermining the very agility they seek to achieve.

Data Delivery Platform

The Data Delivery Platform emerges as a foundational capability for modern enterprises. At its core, it is a curated set of web services—preferably RESTful APIs—that provide standardized, governed access to enterprise data. These services may expose aggregated views of employee, customer, and financial data, as well as enable access to streaming analytics, internal product systems, and external partner ecosystems.

From a CIO perspective, this platform is not simply an integration layer—it is a strategic asset. It establishes a scalable, reusable foundation that reduces duplication, accelerates development cycles, and enables consistent data access across the organization. As stewards of this capability, IT organizations must ensure its availability, performance, and security, while continuously evolving it to meet changing business demands.

Equally important is the concept of data certification. A platform is only as valuable as the trust placed in the data it delivers. Inaccurate or incomplete data erodes confidence and limits adoption. CIOs must therefore lead cross-functional efforts to institutionalize data governance, ensuring that data is accurate, consistent, and fit for purpose. Certified data is what transforms a technical platform into a trusted enterprise service.

Self-Service Zone

The role of IT is undergoing a fundamental shift—from a centralized service provider to an enabler of business-led innovation. As business users seek greater autonomy, IT must respond by delivering self-service capabilities that balance empowerment with governance.

This requires rethinking the enterprise technology stack to include Platform-as-a-Service (PaaS) capabilities that support a wide spectrum of users—from developers leveraging APIs and programming frameworks to analysts utilizing ETL and data integration tools. By standardizing access through a common platform, organizations can provide flexibility without sacrificing control.

Importantly, this model does not diminish the role of IT—it elevates it. IT becomes the architect of platforms, the curator of data, and the guardian of standards. Whether business units choose to partner with internal teams or external consultants, a unified platform strategy ensures consistency, accelerates delivery, and fosters a culture of innovation across the enterprise.

Final Thoughts

While business agility is often the most visible outcome of a Data Delivery Platform, the broader implications are transformational. By decoupling data from applications, organizations can significantly reduce the cost and complexity of development and maintenance. This architectural approach also enhances resilience, allowing underlying systems to evolve without disrupting downstream applications—provided that service contracts remain stable.

We are operating in an environment where the pace of change continues to accelerate, and expectations from customers, partners, and employees are higher than ever. In this context, access to data is not just a technical capability—it is a strategic differentiator.

CIOs and technology leaders must take an active role in shaping this future by investing in platforms and practices that make data accessible, trusted, and actionable. Organizations that succeed will not only gain a competitive advantage—they will define what it means to be a next-generation, data-driven enterprise.

• This was Apigee’s second year hosting the conference, and attendance appeared to have roughly doubled compared to the prior year. My sources estimated approximately 1,600 registered attendees, making it one of the larger API-focused conferences I have attended. The overarching message remained consistent: companies must pursue digital transformation, and APIs are a critical enabler for accelerating that journey.

• This year, there was also noticeably more emphasis on how APIs can help address big data challenges and support predictive applications. That direction was reflected in the announcement of Apigee Insights and the big data session track. Insights is a predictive actions platform designed to help enterprises increase revenue and customer satisfaction by powering adaptive applications that anticipate customer needs.

• Apigee also demonstrated a predictive application using Insights. The demo featured an iPhone shopping app that delivered marketing offers based on user behavior. The demonstration used Apigee 127, a model-first toolkit for building enterprise APIs in Node.js on a laptop. The session also included a demonstration of a data scientist using RClient to build predictive models.

• One of the sessions I attended was “Adaptive Applications: Reimagine the Future” within the big data track, presented by Mike Gualtieri of Forrester Research. He made several strong points. He noted that 30% of business decision-makers remain confused about big data, and that big data should be understood as “data++” — all available data, not just unstructured information. He also emphasized that binary data is often overlooked. According to his research, only 12% of enterprises are unlocking the full potential of data because of poor data quality. His core message was that predictive analytics represents the next major wave of innovation. Netflix’s recommendation engine is a strong example of predictive analytics in action. Adaptive applications anticipate customer intent, and APIs serve as the mechanism through which predictive capabilities are delivered. He also stressed that SOA, API, and data warehouse teams must be aligned to create the foundation for predictive application development. He recommended looking at Apache Mahout, Weka, machine learning libraries, and the R language for statistical computing and graphics.

• One of the aspects I appreciated most was the dedicated business track at the conference, which is not something you often see at API events. In my view, this is a critical component for companies and for the industry as a whole, especially during the early stages of enterprise API adoption.

• Industry analysts continue to predict that by 2020 there will be 50 billion connected devices worldwide. Against that backdrop, Apigee made a strong case that companies need a Chief Digital Officer (CDO) to serve as executive sponsor and champion for digital transformation. In some organizations, this may be a new role; in others, it may be an expanded responsibility for an existing C-level leader. More importantly, it is someone who can communicate the opportunities of digital transformation rather than focusing only on the risks, and who can help educate the broader management team on what the transformation means for the business.

• Apigee also introduced something unique during the keynote: the Digital Accelerator Awards. These awards recognized customers who are leading the way in digital transformation. Some of the winners included Pearson, Walgreens, and McCormick.

• In a panel discussion with Walgreens, Accenture, and Tradier, the speakers noted that industries are increasingly using APIs to leapfrog more advanced competitors and create advantages that may not have been possible otherwise. Their recommendation was to focus less on cost and more on business value and return on investment.

• Another panel, “Digital Transformation: Beyond the Bits”, again emphasized the importance of the CDO and the role of ROI. The panelists suggested that the CDO is not only needed to align the executive team, but also to help establish governance models that allow the business to prioritize and adopt the transformation journey effectively.

• In the panel discussion Digital Pioneers, featuring Edmond Mesrobian of Expedia, Jerry Wolfe of McCormick, and Joe Tobolski of Cognizant, the conversation focused on innovation and enterprise adoption. The cost of experimentation is falling, which makes it easier to test new ideas quickly. At the same time, experimentation must be paired with fast feedback loops and measurable outcomes. Ideas that seemed experimental a year ago may now be highly relevant, since customers are adapting quickly. One of the major challenges ahead is getting analytics into APIs and making models callable. Companies will need to prove value through results. They will also need talent that is curious, passionate, and motivated to solve business problems rather than simply execute IT work. Bringing developers into the conversation helps empower them and improves the organization’s ability to innovate. The challenge for many companies will be to pivot and scale effectively in the new digital economy. Those who invest wisely are likely to see the greatest returns.

• The final session I attended was on Hypermedia within the API track. LL Bean presented its use of hypermedia and shared that it has been evolving its API catalog since 2003. Their goal was to improve developer usability through hypermedia. However, the implementation introduced additional testing complexity and required a shift to behavior-driven development (BDD). The hypermedia specification is still evolving, and broader tool support will be needed to encourage adoption, including hypermedia browsers.

Overall, this was an excellent conference produced by Apigee. The event brought together a highly engaged group of API developers and business leaders eager to learn and share ideas. Fort Mason is a strong venue, although many sessions were difficult to hear because the rooms were separated only by large curtains, allowing noise to carry between spaces. Arriving early and sitting near the front helped. Apigee is growing, the API market is growing, and more companies are looking for a competitive edge. That is a strong recipe for continued success. I am looking forward to next year’s conference.

Although this was a relatively small conference, the attendees were highly engaged and deeply passionate about the topic. I was also struck by how strongly people were thinking about emerging business models in the automotive industry. Below are my notes from each speaker.

Larry Burns

Advisor for Google Self-Driving Cars and Former VP of R&D at GM

Topic: Is the auto industry today evolutionary or transformational?

• Larry opened with a historical view of the automobile industry. For more than 100 years, the automobile has evolved gradually in the United States, with innovations introduced in phases over time. His central point was that the industry has changed very slowly, but we are now approaching a period of significant transformation.

• He noted several key statistics, including approximately 1 billion automobiles worldwide and 1.2 million fatalities. He contrasted the industry’s traditional DNA with what he sees as the emerging model: Connected, Electric, Shared, Driverless, Tailored (speed, weight, and distance), Lower cost with a better mobility experience.

• [VIDEO] Google’s Driverless Car: A First Drive

• Larry also discussed how Google evaluated Ann Arbor, Michigan, and New York City to improve the transportation experience. They concluded that they could reduce the cost of a trip from $7 to $1 while also improving the experience. His view was that the industry is moving from selling vehicles, gas, and insurance to selling miles, experience, and time savings.

• He predicted that a driverless automobile could become a reality by 2017 through Google, and he framed the long-term vision as a fully integrated mobility system designed to create a better customer experience.

Kin Lane

Thought Leader and President of API Evangelist

Topic: The technology, business, and policies of APIs

• Kin raised an important strategic question: why do we need a car in the first place? His point was that consumers now have more alternatives than ever, including taxis, Uber, rental cars, car sharing, trains, public transit, and even motorized alternatives. He also noted that teenagers increasingly have little interest in owning cars, and that telecommuting has become far more common than it was a decade ago.

• He emphasized that entrepreneurs entering this highly regulated industry must understand the real obstacles facing consumers. He also noted that these new opportunities will create a substantial big data opportunity.

• A major theme in his presentation was the politics of APIs. He argued for greater collaboration and transparency across consumers and developers, along with trust, clarity around ownership, and strong respect for privacy. He also made the presentation materials available publicly through GitHub and API Evangelist.

Nick Muerdter

Application Engineer for the U.S. Department of Energy

Topic: Public APIs that support the evolution of the auto industry

• Nick discussed the public APIs his team is building for the U.S. Department of Energy to help support innovation in the automotive space. He shared that the U.S. spends approximately $1 billion to import oil and that the Department of Energy is focused on replacing, reducing, and ultimately eliminating fossil fuel dependence.

• The APIs currently available to developers focus on helping users find alternative fuel stations. The broader goal is to make more government data available through public APIs so developers, and ultimately consumers, can use it in mobile applications and vehicles. His message was clear: the entire effort is about supporting drivers.

• He also described the next version of these APIs, which will need to address the realities of electric fueling. That includes real-time station availability, charging time remaining, open stations, incentive programs, cost calculators, support for both light- and heavy-duty vehicles, and fuel reduction planning tools.

Sid Bhatia

Program Director, API Economy for IBM

Topic: Driving real value with APIs and connected cars

• Sid focused on the business value of connected vehicles. He shared a projection that 20% of cars are expected to be fully connected by 2020. Connected cars generate significant amounts of data, much of it unstructured, and he stressed the importance of trustworthy data in order to make meaningful decisions.

• He described several common API usage patterns: Monetize, Optimize, Extend, and Control.

• He also outlined a wide range of use cases, including roadside assistance, concierge services, third-party applications, remote services such as finding and unlocking a car, predictive maintenance, condition awareness, vehicle-to-anything communication, insurance pricing, fuel efficiency, pay-per-drive models, geofencing, and automated pickup and drop-off.

• Examples such as Peugeot’s streaming analytics and third-party API use, Car2Go’s keyless access apps, and Sprint Velocity for connected cars reinforced his point that the future of connected vehicles will be driven by ease of use, internet-scale connectivity, location awareness, real-time analytics, and monetization through APIs.

Panel Discussion

• During the panel discussion, several speakers reinforced the idea that software, hardware, and automotive companies are converging. The industry is still defining the players, much like the early days of the automobile before consolidation took hold.

• The broader message was that this is an emerging market where virtual and physical worlds are beginning to collide. There are significant overlaps, and organizations need to identify opportunities by focusing on negative scenarios that create urgency for change. Progress will likely be incremental. For example, parking is a pain point that many companies are trying to improve through applications and services.

• Another important observation was that APIs are becoming much more visible to business leaders than they were just a few years ago. Automotive executives increasingly view APIs as products and services that can enhance the customer driving experience, whether through offerings such as OnStar or Tesla. They see them as strategic investments that will help ensure competitiveness in the future.

• One especially notable comment was that Tesla is open-sourcing all of its patents, which is a strong signal of how quickly this industry is changing. The overall impression was that middleware is increasingly becoming the operating layer for this new ecosystem.

  ---

• While it was not explicitly stated in the keynotes, Informatica appears to be positioning itself as a real-time data intelligence company. This direction was reflected in the introduction of SpringBok and Vibe Data Stream.

• Across the keynotes and breakout sessions, there was significant emphasis on enabling end users through self-service capabilities. This theme was reinforced during a special demonstration of SpringBok in the Day 2 keynote. A recurring sentiment throughout the conference was that IT is often perceived as too slow to meet business needs.

• Several data points highlighted the cost of weak data strategy: a $157 per record privacy penalty, with the potential for those penalties to increase over time; approximately 50% of merger and acquisition synergies are IT-related, including data migration, systems of record, and data modeling; M&A data is critical for cross-sell and up-sell opportunities, making master data a major use case; and companies now generate more unstructured data than ever before, while employees spend only about 12 minutes per day working in structured data applications.

• I participated in a hands-on session for Vibe Data Stream (VDS). The live demo was not fully functional, so the product was discussed conceptually instead. VDS is designed for real-time streaming analytics and aims to reduce latency so business users can make decisions closer to real time. It reads unstructured data and streams it into RulePoint, another Informatica product used for visualization and alerts.

• I also had the opportunity to have lunch with Eric Johnson, CIO of Informatica, and Kristin Kokie Deng, VP of Enterprise Strategic Services. We discussed IT challenges, the services each of us uses, and our respective experiences. We also discussed Informatica’s internal MDM implementation. Both Eric and Kristin were candid about the challenges they encountered, which I appreciated. They strongly emphasized the importance of people alignment before technology, including business alignment, data definitions, governance, and business process change.

• I attended a Data Architecture session that focused heavily on self-service analytics and data aggregation. The session was well attended and included many experienced data professionals, but it also felt as though there was limited innovative thinking from the audience. Many attendees raised concerns about waterfall delivery models and the perception that IT was too slow to deliver. There were also repeated comments about the need to engage the business more directly and bring business stakeholders to the table earlier.

• I also participated in a hands-on session for Data Integration Hub. This product had been acquired roughly a year earlier and is used to help Informatica customers reduce reliance on point-to-point ETL integrations. It operates somewhat like a JMS queue or topic, but persists data in a structured database rather than memory. According to the product manager, it is not the right choice for organizations seeking a real-time vision, as it was designed primarily to support large batch jobs from PowerCenter ETL.

• Throughout the conference, I spoke with many Informatica customers, product managers, and partners. Informatica clearly has a highly committed customer base, but many of those customers continue to struggle with point-to-point integrations. One customer I spoke with over lunch described an environment with hundreds of point-to-point ETL integrations and a team of more than 30 people, including contractors and full-time employees, just to manage them. Many customers also expressed a desire to move toward real-time integration, but were uncertain how to do so, particularly given their significant investment in Informatica.

• When I shared my company’s vision of an API self-service model, people were highly engaged and enthusiastic. Many expressed interest in adopting a similar approach within their own organizations. However, there was little discussion in the keynotes or breakout sessions about enterprise APIs. The overall focus appeared to be on real-time streaming analytics.

• I also attended several MDM sessions where every panel expert reinforced the same core message: focus on people first and technology second. Business process socialization and governance were recurring themes. The speakers recommended identifying critical KPI metrics before implementation begins so that ROI can be measured effectively for business stakeholders. They also advised looking first at the business object layer to define terms such as “Ticket” or “Purchase Order,” rather than getting bogged down too early in field-level definitions. Above all, they stressed the importance of starting small and avoiding the temptation to solve everything at once.

Overall, it was an excellent conference with a highly engaged group of Informatica customers, partners, and employees. As the market continues to shift toward the Internet of Things (IoT), Informatica appears to be repositioning itself as a leader in real-time data intelligence. Given the breadth of its software portfolio and the loyalty of its customer base, the company is well-positioned to capitalize on that opportunity.

These are the types of projects that add real value and help move the business forward. At the same time, they can create significant strain on enterprise architecture. More importantly, when point-to-point (P2P) integrations are used, they can negatively affect the organization’s long-term financial outlook. The question, then, is why companies continue to implement P2P integrations instead of adopting a more flexible service-oriented architecture (SOA). Several reasons are clear, while others are less obvious than they may first appear.

The Economics of Budgets

Budget constraints are one of the primary reasons P2P integration solutions continue to be implemented instead of SOA. In many IT organizations, funding is established at the project level. An executive sponsor is identified, funding is allocated, teams are formed, and the project moves forward. This approach is logical and often difficult to challenge.

Under this model, P2P integrations are frequently the fastest and least expensive option in the short term. The integration effort is contained within the project budget, which means technical teams are not carrying requirements unrelated to the immediate business solution, and managers are not incurring costs that appear disconnected from the project objective. However, as Enterprise Architect Marc Rix notes in “Bottom Line SOA: The Economics of Agility”, this approach can create long-term financial consequences for the business.

Those long-term consequences are often difficult to quantify when short-term delivery goals take priority. In many cases, the organization may not experience the full financial impact of a P2P model for years. By that point, the original sponsor may have moved into another role, budgets may have been reallocated, and priorities may have shifted. Building and sustaining SOA requires patience and executive discipline, in part because the initial investment is significantly higher than a P2P implementation. The pressure to manage short-term budgets is one reason many organizations never make the transition to SOA and continue to absorb the cost of a less scalable architecture.

Transitioning to Change

I do not claim to have all the answers, because there is always more than one way to solve a problem. However, recognizing that a problem exists is the first step. Having the EAI program sponsored by business projects may eventually create momentum, but the team must remain disciplined enough to design for the enterprise rather than for a single project. That discipline becomes especially important when key architectural decisions are being made.

If one decision is allowed to favor the project because of time or budget constraints, it can quickly establish a precedent that is difficult to reverse. Real progress toward SOA depends on executives revisiting the budgeting model for enterprise functions and allocating funds in a way that supports the broader needs of the organization, not just the immediate needs of a single project.

Dashboards are especially valuable for management teams that need to monitor key performance indicators across the organization in real time. They also help establish a single source of truth for business data. In the past, managers often spent significant time compiling data from multiple systems into spreadsheets and rolling that information up for executive review. Dashboards eliminate much of that manual effort. They are also an effective way to share summary-level information with users while still controlling access to detailed records. For example, support representatives may see overall sales performance without viewing individual opportunities, and regional teams may compare performance across regions without seeing all underlying opportunity data.

Dashboards also play an important role in building executive support for Salesforce. Executives are busy, and the ability to view sales, marketing, support, and other key information in one graphical format is highly valuable. For that reason, it is worth considering scheduled dashboard emails for executives so critical metrics are delivered directly to their inboxes. This keeps key stakeholders informed quickly and encourages deeper engagement with Salesforce when more detail is needed.

When designing dashboards for users and executives, keep the following points in mind:

1. Accurate Dashboards and Reports: Dashboards are only as strong as the data behind them. Data quality must be enforced to ensure meaningful reporting.

2. Data Refresh: When a dashboard is refreshed, the updated data is available to anyone in the organization with access to that dashboard. Additional refresh requests during the process are ignored, and users can continue working in Salesforce while the refresh runs.

3. The Running User: The running user determines which data appears in a dashboard based on their security access. For static dashboards, all viewers see data according to the running user’s access rights. For dynamic dashboards, the running user can be set to the logged-in user so each viewer sees data based on their own access.

Getting Started with Dashboards

Once you recognize the value of dashboards, the next step is to define which ones will deliver the most business impact. A good starting point is to survey management and key Salesforce users to determine the most important views, regardless of whether the data is already fully captured in Salesforce. Meeting the needs of management and influential users is often critical to building support for the broader Salesforce implementation.

As discussed in a previous post on change management, you can also use the same request channels, such as Cases, Ideas, and Chatter, to collect dashboard requests from users. This creates a structured and visible process for gathering business needs.

The following are the highest-priority areas to consider when starting to build dashboards:

• Survey Top Management: What information does the CEO, VP of Sales, VP of Marketing, VP of Support, and other leaders need to run the business effectively?

• Survey Top Salesforce Users: Use Salesforce administration reports to identify your most active users. What information do they need on a daily basis? What would make their work easier? What would they want in an ideal environment?

• Survey All Salesforce Users: What information would improve day-to-day productivity for the broader user base, such as prospecting data or lead age information?

• Data Requirements: Does your Salesforce environment currently contain the data requested by executives and users? You may need to reconfigure Salesforce by adding or updating custom fields, page layouts, workflow rules, or related functionality to support these needs.

I hope this post helps you learn more about how dashboards can strengthen Salesforce adoption and executive visibility. Please feel free to share your thoughts or dashboard best practices in the comments.

A dashboard is a collection of components that visually present report data and provide a snapshot of key metrics and performance indicators. Together, reports and dashboards help organizations present Salesforce data in a way that enables more meaningful decision-making and allows executives to manage in real time from within the system.

Reports are essential for delivering clear quantitative metrics and serve as the foundation for dashboards. Let’s review report formats, report security, and how to get started with reports. Salesforce supports four report formats, each with a different level of functionality and complexity. We’ll begin with the simplest format.

Tabular Reports

Tabular reports are the simplest and fastest way to view data. Similar to a spreadsheet, they consist of an ordered set of fields in columns, with each matching record displayed in a row. Tabular reports are best for creating record lists or a list with a single grand total. They cannot be used to group data or create charts, and they cannot be added to dashboards unless rows are limited. Common examples include contact mailing lists and activity reports.

Summary Reports

Summary reports are similar to tabular reports, but they also allow users to group rows of data, view subtotals, and create charts. They can be used as the source report for dashboard components. Summary reports are useful when you want to show subtotals based on a particular field or create a hierarchical view, such as all opportunities for a team subtotaled by stage and owner.

Matrix Reports

Matrix reports are similar to summary reports, but they allow data to be grouped and summarized by both rows and columns. They can also be used as the source report for dashboard components. Matrix reports are especially useful when comparing related totals across large volumes of data, or when you want to analyze information by date and by product, person, or geography.

Joined Reports

Joined reports allow you to create multiple report blocks that provide different views of the same data. Each block functions like a sub-report, with its own fields, columns, sorting, and filtering. A joined report can even include data from different report types.

Report Security

Salesforce security extends naturally into reports to ensure that users only see data they are authorized to access. This includes records they own, records they have read or read/write access to, records shared with them, and records owned by or shared with users in roles below them in the hierarchy. In general, if a user can view the data, they can report on it.

In addition, users can only view fields that are visible through page layouts and field-level security settings. Field-level security is available in Enterprise, Performance, Unlimited, and Developer Editions, and can be added to Professional Edition for an additional fee.

Getting Started with Reports

Salesforce makes it relatively easy for users to run reports through an intuitive Report Builder. When creating reports, it helps to have someone who understands the objects being reported on and how those objects relate to one another. In other words, familiarity with the data model is important. This may be the owner of the data or the Salesforce Administrator.

Salesforce comes preconfigured to report across all standard objects. As a starting point, I recommend using standard reports as the foundation for your custom reports.

I hope you found this introduction to Salesforce reports helpful. I also encourage you to review Salesforce’s Quick Start series on Reports and Dashboards to learn more about this important capability.

For this post, I will focus on the different types of training you can incorporate into your broader training program.

Prerequisite Training

A strong training program should begin with prerequisite training. This type of training helps build awareness and create excitement among employees before formal instruction begins. At a minimum, it may consist of short video recordings or concise reference materials that explain the purpose and goals of the training. Most importantly, it should answer the employee’s question: “What’s in it for me?”

Train-the-Trainer

The Train-the-Trainer model is exactly what it sounds like. It involves preparing internal instructors or champions who will ultimately train end users using the materials developed to support the company’s overall training strategy. This approach often works well in organizations where employees are empowered to take ownership of business processes and decisions.

Training for this audience should include an overview of the overall training strategy as well as the content for the specific classes they will be delivering.

Management Training

Management training is often overlooked, yet it can be one of the most important components of a successful adoption strategy. If managers do not understand and support the Salesforce strategy, they can unintentionally become barriers to adoption. The goal of management training is to align the leadership team with the objectives of the Salesforce implementation and equip them to reinforce the expected behaviors within their teams.

This type of training should include presentations from the Salesforce executive sponsor that explain the implementation objectives and answer the question of “What’s in it for me?” from a manager’s perspective. A balanced format of brief presentations and hands-on exercises can be effective. It is also important to cover company policies and procedures related to Salesforce usage and provide supporting materials that managers can reference after training so they are prepared to respond to questions from their direct reports.

End-User Training

End-user training is often the most visible part of a training strategy, and for good reason. Its purpose is to provide hands-on, role-specific instruction that helps employees use Salesforce effectively in their day-to-day work. When in-person training is not possible, virtual training is an effective alternative for remote employees.

As with management training, sessions should include executive sponsor participation to reinforce the business objectives of the implementation. A combination of short presentations and practical exercises tends to work well. Training should always answer the question of “What’s in it for me?” from the employee’s perspective. Supporting materials such as handouts or cheat sheets are also useful, as they give employees a reference they can use after training when performing their roles.

Brown Bag and Lunch & Learn Sessions

Brown Bag and Lunch & Learn sessions are an effective way to keep the training conversation active after formal instruction has ended. These sessions create an informal setting where broader or more advanced topics can be covered. They are also useful for onboarding new employees or for helping team members who were not directly involved in initial training build familiarity with the platform.

These sessions give trainers and executive sponsors an opportunity to gather feedback that can be incorporated into the overall training program. The most effective sessions often include demonstrations of new features, discussion of advanced topics, or open Q&A. Another valuable approach is to have power users share how Salesforce has helped them achieve business results.

Thoughtful training is one of the most effective ways to support adoption and reinforce the value of a Salesforce implementation. While strong training requires planning and effort, it also requires ongoing commitment. When training is approached strategically, it becomes a powerful tool for driving alignment, confidence, and sustained usage across the organization.

For CIOs and other senior leaders, this is not simply an operational question. It is a strategic one that affects agility, governance, user satisfaction, and the ability to scale the platform in alignment with business priorities.

Staffing Considerations

Your organization must determine how many Salesforce administrators are needed and what type of support model best fits the business. Several staffing approaches are available, depending on the size, complexity, and maturity of the Salesforce environment.

Full- or Part-Time Administrator

Depending on business needs, you may choose to employ a full-time or part-time administrator to handle day-to-day requests, manage the Salesforce environment, and ensure the platform is being used effectively.

Separate Administrators

If multiple business units rely on Salesforce, such as Sales, Marketing, Support, and Professional Services, consider assigning separate administrators to support each function. This allows each administrator to focus on the needs, processes, and priorities of their respective business group.

Delegated Administrators

For larger implementations, delegated administrators can be assigned to handle specific tasks such as user management, object customization, or report development. This model can improve responsiveness while reducing bottlenecks in the central administration team.

Regional Administrators

If your company operates across multiple geographies, it may make sense to assign administrators by region, such as AMER, APAC, EMEA, and LATAM. Regional differences in currencies, languages, and business processes should be taken into account. In these cases, it is also useful to appoint a lead analyst or administrator to coordinate across regions and maintain consistency.

Developers

If your requirements extend beyond standard Salesforce configuration, you should consider certified Salesforce developers. This becomes especially important when the business requires custom applications or code-based solutions that go beyond metadata-driven capabilities.

Backup Administrators

Backup administrators are an important part of operational resilience. They should be identified early and kept current on the platform. A practical guideline is to allocate approximately 10 to 25 percent of one full-time employee’s time to backup administration coverage.

Outsourced Administrators

For some organizations, outsourcing administration to a reputable Salesforce-certified consulting partner may be the most effective option. This can provide access to specialized expertise while allowing the internal team to stay focused on governance and business alignment.

Capacity Considerations

It is easy for a Salesforce administrator to become overwhelmed by requests from across the business. That makes capacity planning an important part of your staffing decision. The following ratios can serve as a guideline:

• 1–30 users → 1 full- or part-time administrator

• 31–74 users → 1 or more full-time administrators

• 75–149 users → 1 senior administrator and 1 junior administrator

• 140–499 users → 1 business analyst and 2–4 administrators

• 500–750 users → 1–2 business analysts and 2–4 administrators

• More than 750 users → Staffing varies based on complexity and organizational factors.

These ranges are not absolute, but they provide a useful starting point for planning. In practice, the right model depends on the number of users, the complexity of the business processes, the extent of customization, and the pace of change across the organization.

From a CIO perspective, Salesforce staffing should be treated as part of the broader operating model. The goal is not simply to assign enough people to keep the lights on. The goal is to build a support structure that can sustain adoption, support growth, and enable the business to move quickly without creating control issues.

A well-designed staffing model balances responsiveness, technical capability, and business alignment. As Salesforce usage expands, the staffing model should evolve with it. Thoughtful capacity planning helps ensure that Salesforce continues to deliver value as the business grows.

Managing change in an on-demand environment is similar to managing change in a traditional client-server IT environment. However, there are important differences that Salesforce administrators should understand. To effectively and efficiently manage your organization’s Salesforce application, it is important to understand the key concepts and best practices associated with change management in the platform.

Defining a Program

A well-defined change management program is centered on continuous improvement. It begins with a clear vision and strategy that define the overall goals you are trying to achieve. After establishing that vision and strategy, you must continuously initiate and plan projects that support the program. Salesforce provides some of this through its feature releases; however, it remains important to work closely with end users and executives to identify opportunities for new applications or custom functionality that improve the user experience and help drive adoption. Next, you must operationalize the key functional components and continually validate results, making adjustments as needed.

The main points for a successful change management program are:

1. Vision & Strategy: Establish a change management program that defines a strategy to achieve objectives and ensure progress.

2. Initiate & Plan: Identify the key Salesforce capabilities required to support the change management objectives and develop a roadmap for implementing changes.

3. Operationalize: Build, configure, and deploy applications using the on-demand release management approach, and drive adoption of new features and customizations.

4. Validate: Continually monitor performance metrics, audit data, and use the results to drive behavior or process change within the organization where appropriate.

Implementing Change Management

Once you have established a change management program, you can use the following implementation steps to improve your success when managing change requests in your Salesforce environment.

• Collecting Change Request Ideas

• Analyzing & Prioritizing Change Requests

• Configuring, Implementing, & Testing Change Requests

• Developing an End-User Communication Strategy

Let’s explore each of these points in more detail.

Collecting Change Request Ideas

The first implementation step is to collect ideas and requests from users regarding the functionality they would like to see in the Salesforce application. Creating a clear outlet for users to submit requests is a critical part of adoption. Without one, many users may look for other ways to solve their problems and ultimately move away from the Salesforce implementation. Salesforce offers three best-practice tools that I recommend for collecting change request ideas.

• Salesforce Chatter: Creating a Chatter Group, such as “Salesforce Change Requests,” is a useful way to gather feedback from your user base. Chatter is similar to Facebook for the enterprise. Because it is a real-time collaboration tool in the cloud, it can provide secure, immediate communication in a familiar social-style interface. It is built on the robust and secure Force.com infrastructure. Users can join your Salesforce Change Requests Chatter group, post change request ideas, and comment on other posts. All messages are available as a feed that users can subscribe to.

• Salesforce Cases: Cases are another effective way to collect feedback from internal users. A user can submit a case with the details needed for the request. If you use this method, I recommend creating a Case Record Type for internal enhancement requests so that external support requests are not mixed with other case types, such as external customer cases. Creating a Case Record Type also helps with list views and reporting. With this approach, the administrator or change management committee can evaluate requests using Salesforce reports and dashboards to monitor the number, type, frequency, release schedule, and other characteristics of the requests.

• Salesforce Ideas: Depending on your Salesforce edition, the administrator can configure Salesforce Ideas as a simple and efficient way for internal users to submit enhancement requests. When a user submits an idea, other users can review it and vote on the ideas they value most, allowing the top-voted items to rise to the top of the request list. In this way, users can help drive prioritization. The administrator or change management committee can also interact with users by posting comments on the idea request. This two-way interaction creates a collaborative environment and gives users a channel to voice their needs. Salesforce uses this same approach on its IdeaExchange site to gather product ideas and receive feedback.

These are just a few examples of tools that can help manage change in your Salesforce environment. Using the same methods to engage the internal user base that you use with customers demonstrates your company’s commitment to Salesforce. Users are more likely to adopt Salesforce when their voice is heard through channels such as Chatter, Cases, and Salesforce Ideas.

Analyzing & Prioritizing Change Requests

Analyzing and prioritizing change requests should be done by a Salesforce change management committee that meets regularly to review and schedule large, complex enhancement requests. The committee should be cross-functional, with members representing both administration and the business units that use Salesforce. A well-defined committee ensures that changes likely to affect the broader Salesforce environment, such as changes to global settings or organizational business processes, are discussed and assessed appropriately. Everyone involved should understand the impact on their respective business units or processes.

In addition to reviewing, prioritizing, scheduling, and approving requests, the Salesforce change management committee should also be responsible for monitoring overall application usage, evaluating key metrics, and developing tactics to drive and maintain user adoption.

Configuring, Implementing & Testing Change Requests

Managing a client-server environment differs from managing an on-demand environment. In the old client-server model, companies and organizations invested significant time and resources in building development, test, and staging environments to develop and test changes. Fortunately, Salesforce provides an on-demand sandbox environment. Depending on your licensing agreement, you can configure one or more separate sandbox environments with the click of a button. Refreshing a sandbox is equally simple. Salesforce allows sandbox refreshes every 30 days to keep test environments synchronized with production.

I recommend that all companies, large or small, use configuration or developer sandboxes for development and test environments, and use full sandboxes for staging or training. Configuration and developer sandboxes provide a copy of all production application and configuration information, but records and data are not copied into those environments. Using configuration and developer sandboxes adds an important security layer and helps prevent unwanted access to sensitive information during development or testing. In contrast, full sandboxes are ideal for staging or training environments because end users can validate changes using their own user accounts and profiles. Using full sandboxes helps ensure that new functionality is configured correctly and that users can complete any necessary training before deployment to production.

You should follow the sandbox methodology when making changes to the following items:

• Workflow and approval processes

• Role hierarchy

• Sharing rules

• Territory management

• Integrations through Web Services or Data Loader

• Apex Code or Visualforce enhancements

• Building custom applications

After testing is complete, use the migration tools provided by Salesforce to move the changes forward, or migrate them manually if the changes are not part of the Metadata API or are simple enough that a specific tool is not required.

The Force.com Eclipse Integrated Development Environment (IDE) provides a fully integrated development environment that developers can use to work with Salesforce application customizations and custom applications programmatically through the Metadata API. The IDE can be used to manage the migration of changes, customizations, integrations, and custom applications between your development, testing, and training environments. I also recommend leveraging Salesforce Change Sets to help automate the migration process across your environments.

Developing an End User Communication Strategy

The Salesforce change management committee must have a training strategy that includes new Salesforce users as well as ongoing training to support new features and configurations as the company grows. Consider supporting multiple groups, different roles, and different learning styles, since the needs of a sales representative and a technical consultant will differ. Lastly, consider using a range of media and communication vehicles to deliver training or information to end users, such as instructor-led training, webinars, newsletters, tips and tricks notifications, or homepage messages and alerts.

A Practical Framework for Data Quality

Companies can manage data quality in Salesforce by following a simple, sequential approach:

1. Analyze

2. Plan

3. Standardize, Cleanse, and Enrich

4. Automate and Integrate

5. Maintain

Let’s look at each step in more detail.

Analyze

The first step in managing data quality effectively is to analyze the data. Take time to understand your sources. For example, are you capturing data through Salesforce Web-to-Lead or Web-to-Case forms, or is most of the data entered directly by the sales organization?

Understanding the source of your data will help you identify its strengths and weaknesses. It is also helpful to assess data quality across key dimensions such as completeness, accuracy, validity, relevance, integrity, standardization, and duplication. Once you establish a baseline rating, it becomes easier to identify problem areas and prioritize improvements.

It is also important to understand how data is mapped and used at both the object level, such as Account, Contact, and Opportunity, and the field level, such as City, State, and Country. This helps prevent duplication and ensures that information is stored consistently across the system.

Plan

A strong data quality program begins with a clear plan. I recommend identifying an executive sponsor who can help secure budget support and drive the initiative forward. It is equally important to assign owners who are accountable for specific areas of data quality. For example, sales managers may be responsible for Account and Contact data, while marketing managers may oversee Lead quality.

Once sponsorship and ownership are established, define and prioritize your goals. These may include targets for completeness, duplication rates, bounce rates, and other key measures. You should also determine how success will be measured and use Salesforce reports and dashboards to create transparency around progress.

A communication plan is equally important. Owners should understand the goals, their responsibilities, and how their performance will be measured. End users who enter data into Salesforce should also be included through kickoff meetings, email updates, or similar communications so they understand the charter, goals, metrics, and incentives.

Standardize, Cleanse, and Enrich

After analysis and planning, the next step is the core of data quality management: improving the data itself. This should be done in a deliberate sequence.

1. Standardize: Normalize values such as country names, postal codes, phone numbers, and job titles.

2. Cleanse: Correct bad or missing data, establish naming conventions, and transform data where needed.

3. Enrich: Add value to existing records through external sources such as Data.com or D&B.

4. De-dupe: Remove duplicate records and establish an ongoing deduplication process.

5. Validate: Use a sandbox to test cleansing efforts before applying them in production.

Taken together, these steps help create a more reliable and consistent Salesforce environment.

Automate and Integrate

Organizations can improve efficiency by reducing the number of manual tasks users must perform. Salesforce provides built-in tools such as workflow rules and approval processes to automate standard business activities. Workflow rules can automatically send emails, create tasks, update fields, or send outbound messages based on defined conditions.

Approval processes can also streamline operations. They define the steps required to approve a record and identify who must approve it at each stage. They can also specify the actions to take when a record is approved, rejected, recalled, or submitted for approval.

In addition to automation, integration with other systems can add significant value. Users are more productive when they do not have to move between multiple systems to complete their work. At a minimum, custom links can connect Salesforce with external applications to create a more unified user experience. When designing integrations, Salesforce External IDs are especially useful because they allow the platform to store unique identifiers from external systems.

There are several paths to successful integration in Salesforce:

• AppExchange Directory: A strong source of prebuilt solutions and integration tools.

• Native Desktop Connectors: Useful for connecting with Microsoft Outlook, Excel, and Word.

• Native ERP Connectors: Support common integration scenarios with systems such as SAP and Oracle.

• Integration Partners: Vendors such as MuleSoft, SnapLogic, Boomi, Jitterbit, Tibco, and Informatica provide certified connectors and middleware solutions.

• Developer Toolkits: Support custom integrations for development environments such as J2EE and .NET.

Maintain

Data quality is not a one-time effort. Even well-designed processes will degrade over time if they are not actively maintained. As a result, maintaining data quality should be treated as an ongoing discipline rather than a short-term project.

There are three best practices for maintaining high-quality

1. Train and Communicate: Educate users early on naming standards, processes, and duplication avoidance. Reinforce that data integrity is a shared responsibility and communicate how the data will be used. Consider testing and certification programs, along with periodic retraining.

2. Enforce: Ensure that ownership and sharing rules are properly configured, since ownership plays a major role in preventing poor data practices. Establish policies around mass imports so they do not compromise data quality. An incentive and disincentive model can also help reinforce the right behavior.

3. Monitor: Use Salesforce reports and dashboards, or third-party AppExchange tools, to monitor data quality over time. Workflow alerts and email notifications can also help keep stakeholders informed.

Data quality is one of the foundations of a successful Salesforce implementation. With the right strategy, governance, automation, and ongoing accountability, organizations can improve both the reliability of their data and the effectiveness of the platform.

That reality led my team and me to invest significant time in developing a long-term integration strategy aligned to the company’s vision of reaching $10 billion in annual revenue. Supporting an organization of that scale requires an architecture that can evolve with the business. As we designed our strategy, we established a set of guiding principles to support decision-making:

1. Cloud First. As a company that helped pioneer the Software-as-a-Service model, it was important that our integration strategy reflect the same cloud-first mindset that defines our broader business. That is easier said than done. Integration platforms are often slower to innovate than other areas of the technology stack, and they do not always adopt emerging trends quickly. We knew this principle would require discipline and careful evaluation.

2. Industry-Leading Technologies. The technology landscape continues to evolve rapidly, and end users increasingly expect enterprise tools to reflect the same modern experience they see in their personal lives. When enterprise IT organizations move too slowly, it can create frustration and reduce confidence in the platform. We wanted an architecture that would allow us to adopt new technologies as business needs changed, or work with a vendor committed to staying aligned with industry direction.

3. Focused on Success. Integrations require technologies that can transform, enrich, and move data reliably to its intended destination. Designing a reusable and consistent platform that can handle high data volumes, ensure delivery, and support analytics introduces significant complexity. We wanted a partner that was genuinely invested in our success and capable of helping us solve difficult architectural and operational challenges along the way.

This led us to evaluate two broad approaches for an enterprise integration platform: a best-of-breed cloud strategy or a more traditional single-vendor on-premise strategy. The chart below illustrates how vendors may map to the major components of each approach.

Strategic Tradeoffs

At a high level, each model has distinct strengths and considerations.

Best-of-Breed Cloud Approach

Strengths

• Risk is distributed across multiple vendors.

• Best-in-class products can be selected for each function.

• Lower total cost of ownership and a smaller hardware footprint.

Considerations

• Multiple cloud vendors may be required to complete the platform.

• Custom development may be necessary to close security or functional gaps.

• May be more suitable for smaller companies or acquisition targets.

Single Provider Approach

Strengths

• Mature company and product offering.

• Can support future growth and maturity.

• Simplified accountability with a single vendor relationship.

Considerations

• Greater vendor lock-in.

• Higher total cost of ownership due to hardware and support.

• May not fully align with a cloud-first vision over time.

In the end, our experience reinforced the value of working with multiple vendors that excel in their respective domains. A best-of-breed cloud strategy can provide the depth and flexibility needed to support future change. Just as importantly, it can energize integration teams by giving them access to leading technology rather than forcing compromise around a single stack.

From a CIO perspective, adoption should be evaluated across three dimensions:

1. Usage

2. Data Quality

3. Key Performance Indicators

Each provides a different level of insight into how well Salesforce is embedded in the organization.

Usage

The most basic indicator of adoption is login activity. Salesforce offers standard reports that can help IT and business leaders understand whether users are consistently engaging with the platform. One useful report is “Users Logged in This Week”, which identifies users who accessed Salesforce in the past seven days. This report can be adapted to monitor different timeframes or flag inactive users.

These reports are useful for establishing expectations by user group, including sales, service, and operations teams. Recommended usage metrics include:

• Users Logged In, Last 7 Days — Weekly

• Users Not Logged In by Last Name, Last 7 Days — Weekly

• Users Never Logged In — Weekly

• Accounts Created by Owner Role, Last 120 Days — Monthly

• Accounts Created by Owner Role, Last 120 Days — Monthly

• Opportunities Created by Owner Role, Last 60 Days — Monthly

• Contacts Created by Owner Role, Last 120 Days — Monthly

• Activities Completed, Last 60 Days — Monthly

• Neglected Opportunities by Role, Next 60 Days — Monthly

• Open Tasks by Assigned Role, Current and Previous — Quarterly

Data Quality

Usage alone does not tell the full story. A CIO also needs to know whether users are entering complete, accurate, and actionable data. Poor data quality often signals weak adoption, inconsistent process discipline, or insufficient training.

A practical approach is to measure object ownership and data completeness across core Salesforce objects such as Accounts, Contacts, and Opportunities. Tracking creation patterns by user and by role can reveal where the application is being used effectively and where it is not. It can also help identify data gaps that may reduce reporting accuracy or operational effectiveness.

Recommended data quality metrics include:

• Opportunities with a Close Date, Last 60 Days — Monthly

• Stage Opportunities are Entered — Monthly

• Prospect Account Missing Number of Employees, Last 60 Days — Monthly

• Lead Rating on Converted Leads — Monthly

• Accounts with All Key Fields Populated — Monthly

• Accounts Missing Rating Field — Monthly

• Key, Non-Required Fields Filled Out — Monthly

Key Performance Indicators

KPIs are the most mature and business-relevant way to assess adoption. They go beyond activity measurement and show whether Salesforce is helping the organization improve performance, enforce process discipline, and support management decision-making.

If leaders are not using Salesforce dashboards and reports to review KPIs, the platform may be functioning more as a data repository than as a management system. For that reason, KPI design should involve managers, senior leaders, and executives so the metrics reflect business outcomes rather than just system activity.

Without a defined KPI framework, adoption quality, reporting consistency, and data integrity can all decline over time. Recommended KPI metrics include:

• Pipeline by Owner or Owner Role — Monthly

• Monthly Sales Trends — Monthly

• Activity Type by Assigned Owner — Quarterly

• Win Ratio for Current and Previous Fiscal Year — Quarterly

• Open Leads by Owner Role, Open Not Contacted — Quarterly

• Deal Type by Owners Winning, Current and Previous — Quarterly

• Deal Type by Owners Losing, Current and Previous Quarters — Quarterly

CIO Perspective

For CIOs, the goal is not simply to measure whether users log in. The real objective is to determine whether Salesforce is changing business behavior in a measurable and sustainable way. Strong adoption metrics provide visibility into usage patterns, data discipline, and the platform’s impact on business performance.

A well-run adoption program should combine operational reporting, data governance, and executive accountability. When those three elements are in place, Salesforce is far more likely to deliver lasting value.

An executive sponsor helps create focus, build alignment, and drive adoption. Rather than treating Salesforce as a broad, open-ended technology program, the sponsor provides leadership around a defined business outcome and ensures the initiative stays tied to measurable value.

The three most important reasons to secure an executive sponsor are:

1. Provide focus for specific Salesforce initiatives.

2. Build and drive management consensus.

3. Create user incentives and adoption momentum.

Provide Focus

The most effective Salesforce programs are usually not launched as large, all-at-once transformations. Instead, successful executive sponsors help narrow the scope to a specific business area, such as lead management, sales execution, or customer support.

A focused approach makes it easier to deliver value quickly and avoids the common pitfalls of a “big bang” rollout. Large-scale change is difficult for any organization because users need time to adapt to new systems, new processes, and new expectations. By breaking the strategy into smaller phases, you give the organization room to absorb change, gather feedback, and adjust before moving to the next stage.

This incremental approach also supports a more agile delivery model, which tends to improve adoption and reduce implementation risk.

Build Consensus

Another critical role of the executive sponsor is to help build management support over time. Long-term CRM initiatives can stall when leadership is unwilling to commit to sustained investment or when progress is difficult to measure.

By sponsoring smaller, visible wins, the executive sponsor can demonstrate value and create momentum across the broader leadership team. Over time, the goal is to shift ownership from one sponsor to a broader coalition of executives so the initiative becomes part of the organization’s operating model rather than a standalone project.

That transition is essential for long-term success. Active executive involvement in review meetings, priority setting, budgeting, and issue resolution helps reinforce alignment and keeps the program moving forward.

Drive Adoption

Executive sponsors can also accelerate adoption by reinforcing the importance of Salesforce from the top down. In practice, this may include setting expectations for system usage, tying Salesforce participation to performance visibility, or recognizing teams that actively engage with the platform.

They can also encourage adoption by making Salesforce reporting part of normal management routines. When leaders ask for updates, dashboards, and forecasts through Salesforce, usage becomes part of the business process rather than an optional task.

Used well, executive sponsorship creates organizational momentum that can significantly improve adoption, consistency, and long-term value.

Executive sponsorship is not just helpful — it is often a deciding factor in whether a Salesforce initiative succeeds. A strong sponsor provides focus, alignment, and accountability, all of which are essential for delivering lasting business impact.

What HTML Email Tracking Does

Salesforce allows users to send HTML emails directly from the platform to prospects and customers. These emails may be simple formatted messages with bold text, colors, and links, or they may be fully designed templates created by your marketing team to promote a campaign, event, or offer.

Once an HTML email is sent, Salesforce can track key engagement details such as the first time the email was opened, the most recent open, and the total number of opens for each recipient. For sales professionals, this information can help prioritize follow-up efforts and focus attention where it is most likely to drive conversion or expansion.

HTML Email Tracking is available across Salesforce editions and can be enabled in two straightforward steps: first, activate the feature in the Activities settings; second, add the HTML Email Status related list to the page layout for Leads, Contacts, or Person Accounts.

How It Works

This feature relies on pixel tracking, sometimes called a web beacon. The concept has existed for years and is widely used across marketing technology platforms to measure email and web engagement.

When an HTML email is sent, Salesforce adds a transparent 1x1 pixel image to the message. The recipient never sees it, but when the email is opened, and images are downloaded by the email client, Salesforce records the open activity. That data is then reflected in the related list for the recipient record.

To review the results, navigate to the Lead, Contact, or Person Account associated with the email and open the HTML Email Status related list.

Important Considerations

While this is a useful capability, it is important to understand its limitations. Many modern email clients block images by default to protect users’ privacy and reduce unwanted tracking. When that happens, Salesforce may not receive the signal needed to record an open.

One practical way to improve the likelihood of image downloads is to include a clear and visually relevant header image in the email. It is also a good practice to use ALT or TITLE text that encourages the recipient to view images, especially if the email includes branding or promotional content.

Privacy and Ethics

As with any tracking technology, it is worth considering privacy implications and company policy before using the feature. Some recipients may view pixel tracking as intrusive, even though it is common in modern email marketing. The key is to ensure your use of the feature aligns with your organization’s standards, legal requirements, and customer expectations.

Ways To Use It

HTML Email Tracking can be used in several ways within Salesforce:

1. Sent individually from a Lead, Contact, or Person Account.

2. Sent through Salesforce Mass Email for Leads or Contacts.

3. Sent through Web-to-Lead and Web-to-Case auto-response rules.

This gives teams flexibility to track engagement across both one-to-one outreach and broader communication workflows.

HTML Email Tracking can provide valuable insight into prospect engagement when used thoughtfully. My recommendation is to treat it as one input among several, not as a standalone measure of interest, and to pair it with sound judgment and a clear outreach strategy.