Setting up an enterprise environmental, social, and governance (ESG) operating system from the beginning involves more than platform configuration. It includes Business Responsibility and Sustainability Reporting (BRSR), supplier emissions, carbon accounting, and the complexity of Scope 3 emissions.
In March 2024, Zensar launched Salesforce Net Zero Cloud as its first enterprise ESG system. Supported by its broader Salesforce services capabilities, the implementation of centralized carbon data enabled the production of BRSR and Global Reporting Initiative (GRI) reports. It made progress toward sustainability goals more visible. The journey was not without difficulties, but the lessons were clear.
The data is nowhere yet
Our first step was to ask a straightforward question: where was our emissions data? The answer was surprising. Capital assets were recorded in Oracle, purchase orders were spread across the system with no clear distinction between goods and services, and although supplier information was available, we could not easily determine which suppliers were linked to which commodities or activities for Scope 3 emissions.
We had financial records and general ledger (GL) codes, but we lacked ESG records. Our finance lead was right when he said: “If you define the purchase of goods and services as anything the company buys, then you’re looking at a figure over $300 million; we need to narrow that down.”
Three weeks into the discovery phase, we realized that we had to establish the Scope 3 methodology before deciding which systems contained the data. The greenhouse gas protocol offers spend-based and activity-based modeling approaches, and each leads to different data sources. We selected the spend-based approach for the first year because our procurement data was cleaner than our commodity data. In the next stage, we plan to move towards activity data as the supplier-engagement process matures.
Don’t assume sustainability data is clean or readily available. First identify what exists, determine the reporting boundary, and document the gaps that must be addressed before configuring the platform.
Integration is harder than configuration
We spent approximately 60% of the implementation effort on data flows and 40% on platform configuration. That ratio was unexpected.
We obtained capital-goods data from Oracle’s fixed-asset module through a direct API call. Purchase data came from several GL accounts because there was no standard product-versus-service classification, so we needed mapping logic to group expenses. We then faced a larger decision: integrate in real time, which would be more complex and costly, or use weekly loads, which would be simpler but less current.
In the FirstSource engagement, which involved a higher-education institution managing campus operations and sustainability reporting, we also had to obtain facility-level energy data from utility platforms and assign it to buildings. Building codes didn't match, and some utility meters covered more than one building, so we reconciled the data and supported it with reference data.
We began with weekly batch loads instead of enterprise middleware. This gave the team time to verify data across systems and identify errors before they entered the reporting process.
In practice, prioritize the two or three most impactful integrations first. Facility data for Scope 1 and utility data for Scope 2 are essential; supplier emissions for Scope 3 should follow once the data-governance foundation is stable.
Scope 3 is a rabbit hole
Sustainability teams often want to complete Scope 3 coverage immediately, including upstream transportation, downstream distribution, employee commuting, business travel, supplier emissions, and end-of-life products across all 15 categories.
We resisted that temptation by launching the minimum viable product with Scope 1 and Scope 2. We introduced Scope 3 in phase two, beginning with purchased goods and services and using spend-based emission factors rather than primary supplier data. We first had to establish governance, stakeholder alignment, and data quality.
When we expanded supplier engagement, we found that many suppliers did not maintain product-level emissions records. Some disclosed broad figures in ESG reports, but the data was not detailed enough for the required analysis. This required practical conversations about what suppliers could reliably provide.
Start small, prove the model works, then expand Scope 3 emissions coverage.
Nobody cares about the dashboard
The real work wasn't designing a dashboard. It was reaching an agreement between finance and sustainability teams. For example, should a vehicle lease be treated as an operating expense for accounting purposes or as capital equipment for emissions tracking? These decisions affect the emissions baseline.
Facility managers also used different units and data-entry methods across regions. Finance organized costs by business unit, while sustainability required data by location. The team therefore had to develop mapping logic, define common data rules, and retrain users.
The turning point was simultaneous executive sponsorship from sustainability and finance. Together, the leaders explained the importance of the data and connected facilities’ incentives with emissions targets. The activity then shifted from additional work to an established operating practice.
Approximately 40% of the implementation involved technology; the remaining 60% involved ESG data governance, change management, and stakeholder alignment.
What success actually looks like
After go-live, we could answer four questions with greater confidence:
What are our current baseline emissions, based on auditable calculations rather than estimates?
Where are we against the 2030 net-zero plan, measured monthly rather than annually?
Which facilities or suppliers are responsible for the emissions, based on data rather than speculation?
What actions and scenarios are required to achieve the target?
For client engagements such as FirstSource, the platform supported BRSR reporting capability and greater confidence in GRI-aligned reporting on the same foundation.
Salesforce Net Zero Cloud can support sustainability data management, reporting, carbon accounting, and emissions analysis, but a successful Net Zero Cloud implementation still depends on a clear scope, disciplined data governance, and realistic timelines.
Organizations should treat the program as a phased, multi-year development rather than a six-month project. Organizations that succeed act deliberately, measure progress honestly, and work with an experienced Salesforce partner to connect the platform with finance, procurement, facilities, suppliers, governance, and reporting processes.
Salesforce Net Zero Cloud FAQs
What is Salesforce Net Zero Cloud?
Salesforce Net Zero Cloud is a sustainability management platform that centralizes ESG and operational data, supports carbon accounting, manages emissions, and produces framework-aligned sustainability reports.
How does Salesforce Net Zero Cloud support ESG reporting?
The platform can consolidate sustainability data, support emissions calculations, and help teams prepare reporting aligned with frameworks such as GRI. Organizations should independently confirm the requirements for BRSR and other jurisdiction-specific disclosures.
Why are Scope 3 emissions difficult to manage?
Scope 3 emissions depend on procurement, supplier, travel, logistics, commuting, product, and value-chain data that may be incomplete, inconsistently classified, or unavailable at the required level of detail.
What should organizations do before implementing Net Zero Cloud?
Define the reporting boundary, emissions methodology, data owners, source systems, integration priorities, governance model, validation process, and phased roadmap before you begin configuring the platform.
What makes a Net Zero Cloud implementation successful?
Success depends on trusted data, cross-functional ownership, executive sponsorship, disciplined governance, practical integration choices, realistic Scope 3 expectations, and continuous improvement after go-live.