app.dataengineerhub.blog

Category: Salesforce

Master Salesforce data integration and analytics. Tutorials on extracting and handling CRM data using Apex, SOQL, MuleSoft, and the Salesforce Data Cloud for robust enterprise solutions.

How Salesforce Data Cloud Zero Copy Actually Works With Snowflake

Your data engineer says the customer data already lives in Snowflake — all of it, clean, modeled, production-ready. Your architect wants to copy it into Salesforce Data Cloud. You’re running the mental math on storage costs, pipeline maintenance, and the inevitable sync drift between two copies of the same truth. This is the exact problem Zero Copy was built to kill.

In Q3 FY2026, Salesforce Data Cloud ingested 32 trillion records in a single quarter. Of those, 15 trillion — nearly half — flowed through Zero Copy connectors, a 341% year-over-year surge. That ratio tells you something important: nearly half of all enterprise data entering Data Cloud never actually enters Data Cloud. It stays exactly where it is, in Snowflake or Databricks or BigQuery, and gets queried in place. No ETL job. No second copy. No 2 a.m. pipeline failure that leaves your Agentforce segments stale.

But here’s the thing most practitioners miss: “Zero Copy” is not one mechanism. It’s two completely different architectures — Query Federation and File Federation — and using the wrong one for your workload is how you end up paying Snowflake compute bills you didn’t expect while solving a problem Salesforce told you was free. This is the guide that breaks both apart.

TL;DR

→ Salesforce Data Cloud Zero Copy has two inbound modes. Query Federation sends a SQL query to Snowflake’s compute, which runs it and returns the result — you pay Snowflake credits for every query. File Federation reads your Iceberg files directly using Data Cloud’s own engines — no Snowflake compute billed at all. Salesforce now recommends File Federation wherever the platform supports it.

→ The outbound direction — Data Sharing — lets external systems like Snowflake read Data Cloud’s enriched outputs (unified profiles, segments, calculated insights) without copying them out. Snowflake uses Secure Data Sharing; Databricks uses Delta Sharing and Unity Catalog.

→ Apache Iceberg is the technical layer that makes File Federation possible. Because both Data Cloud and Snowflake support Iceberg as an open format, Data Cloud can read Snowflake Iceberg tables directly at the storage layer — without a proprietary connector and without Snowflake’s compute firing.

→ Query Federation works for all Snowflake table types. File Federation requires your Snowflake tables to be Iceberg-backed. If they’re native Snowflake tables, you’re on Query Federation and paying Snowflake for each read.

→ The acceleration schedule for a Data Stream can run as frequently as every 15 minutes for incremental refreshes. Understand this schedule before you configure — it’s where your Snowflake credit bill comes from if you’re on Query Federation.

The architecture: two modes, one brand name

Query Federation delegates compute to Snowflake and bills you for it. File Federation uses Data Cloud’s own engines against the storage layer — Snowflake compute never runs.

Underneath the marketing, Zero Copy Data Federation splits into two fundamentally different execution models.

Query Federation is the JDBC model. Data Cloud formulates a SQL query, applies predicate pushdown — filters, aggregations, joins — and ships it over a JDBC connection to Snowflake. Snowflake’s engine executes it against its own tables and returns only the result set. This is efficient because query pushdown ensures Snowflake ships back a small answer rather than a full table scan. It’s also real compute: Snowflake bills you for every query Data Cloud fires, just as if one of your analysts had run it. If your Data Stream acceleration is set to refresh every 15 minutes against a large table, you’re firing 96 Snowflake queries a day on that one object.

File Federation is the Iceberg model. Data Cloud reads your data files directly from the storage layer — the same Parquet files that Snowflake manages — using Data Cloud’s own engines (Spark, Hyper, and Trino, routed automatically by workload type). Snowflake’s compute is never involved. No Snowflake credits fire. You pay Data Cloud’s read costs, not Snowflake’s query costs. The mechanism that makes this possible is Apache Iceberg: because both Snowflake and Data Cloud support Iceberg as an open table format, Data Cloud can read the Iceberg manifest and data files directly without any proprietary connector. The constraint is that your Snowflake tables must be Iceberg-backed. Native Snowflake tables are not eligible; they fall back to Query Federation.

Salesforce now explicitly recommends File Federation over Query Federation wherever the external platform supports it. File Federation is GA for Databricks and generic Iceberg catalogs. For Snowflake specifically, File Federation requires Snowflake-managed Iceberg tables exposed through the Iceberg REST Catalog.

Setting up Zero Copy with Snowflake: what you actually configure

Before you touch any Salesforce UI, the Snowflake side needs preparation. You create a dedicated warehouse, an integration user, and a key-pair authentication setup. The integration user gets scoped grants — at minimum USAGE on the database and schema, SELECT on the tables you’re federating. The key-pair (public/private RSA) is what Data Cloud uses for the JDBC connection in Query Federation, or for the Iceberg REST catalog handshake in File Federation.

On the Salesforce side, the flow in Data Cloud Setup is: create a connector (Snowflake connector type), supply the account URL and credentials, then create a Data Stream on top of that connector. The Data Stream is where you select which Snowflake objects to surface in Data Cloud, map them to Data Cloud object types, and configure the acceleration schedule.

The acceleration schedule deserves careful thought. “Live query” means Data Cloud queries Snowflake at request time — zero persistence, but every Agentforce or segmentation operation that touches this object fires a Snowflake query. Caching (available on Query Federation only) persists data in Data Cloud’s lake and reads from there, which lowers per-operation latency and Snowflake credit consumption on repeated reads. File Federation skips this choice entirely: it’s always live against the storage layer, with no caching option needed because the file-read cost is already low.

Data Sharing: the outbound direction

The direction most tutorials skip is outbound — Data Cloud pushing its outputs to Snowflake rather than reading from it. Once Data Cloud has unified your customer profiles, resolved identities across touchpoints, scored propensity, and built segments, those enriched objects become queryable by Snowflake without any ETL back-out.

Salesforce uses Secure Data Sharing for the Snowflake outbound direction: Data Cloud creates a share that Snowflake mounts as an external object, and your Snowflake analysts query unified profiles and calculated insights as if they were native Snowflake tables — with live data, no copy, no maintenance pipeline. At 800 credits per million rows on the Data Cloud side, this is costlier than inbound federation, but it eliminates outbound pipeline maintenance entirely and ensures analysts are always reading the unified truth rather than a stale export.

Apache Iceberg: why this works without a proprietary connector

The reason File Federation doesn’t need a vendor-specific connector is worth understanding, because it’s also why the integration has limits. Data Cloud internally manages 4 million Apache Iceberg tables spanning 50 petabytes of data, and its query engines — Spark, Hyper, Trino — natively speak the Iceberg table spec. When a Snowflake table is Iceberg-backed, its data is Parquet files with Iceberg metadata in shared object storage. Data Cloud’s engines can read that metadata, identify the data files, and scan them directly — the same way Databricks or Trino would. No Snowflake layer in the request path.

This also explains the limitation: native Snowflake tables use Snowflake’s internal micro-partition format, which is not Iceberg. Data Cloud can’t read that format directly, so it falls back to Query Federation — going through Snowflake’s JDBC interface and paying Snowflake compute. If your organization hasn’t migrated tables to Snowflake-managed Iceberg yet, every Zero Copy read is Query Federation regardless of what your architecture diagram says.

When Zero Copy is the wrong answer

Zero Copy is not always the right architecture, and the 341% adoption surge doesn’t mean it’s universally appropriate. Three cases where you’re better off ingesting into Data Cloud properly:

Complex transformations before Data Cloud use. If the data needs significant modeling or enrichment before it’s useful in segmentation or Agentforce contexts, federating raw Snowflake tables means pushing that compute burden onto every Data Cloud operation. Ingesting clean, pre-modeled data is faster and cheaper at query time.

High-frequency access patterns. Query Federation on a frequently-queried object with a short acceleration schedule fires Snowflake queries continuously. At a certain access frequency, ingestion and native Data Cloud storage is cheaper than accumulating Snowflake credits on every segmentation job.

Regulatory data residency requirements. Zero Copy keeps data in its source system and queries it in place. If your regulatory requirements mandate that Salesforce-accessed data must reside in a Salesforce-controlled environment, Zero Copy may not satisfy that requirement — confirm with your legal and compliance teams, because “data never moves” has a specific legal meaning in some jurisdictions.

The gotchas nobody warns you about

Type compatibility is a real mapping problem. When Data Cloud pulls a Snowflake table into a Data Lake Object via Query Federation, it maps Snowflake types to Data Cloud types. VARIANT, GEOGRAPHY, and some timestamp precision types don’t always map cleanly. Verify your field types in the Data Stream configuration before you build segments on top of a federated table — a silently miscast timestamp can produce wrong results without an obvious error.

Private Connect for VPC-locked Snowflake. If your Snowflake account is locked down in an AWS VPC or Azure VNet private endpoint, standard Zero Copy connectivity won’t reach it. You need Private Connect for Data Cloud enabled, which requires additional network configuration on both sides and is not automatic.

Grants on future objects don’t auto-extend. Zero Copy connects to the Snowflake objects you grant at setup time. New tables added to the same schema are not automatically federated — use GRANT … ON FUTURE TABLES IN SCHEMA proactively during setup so new objects are automatically covered.

The acceleration checkbox. When you create a Data Stream, enabling the “Enable acceleration” checkbox triggers the caching mechanism. Caching behavior and billing implications differ between Query and File Federation — read the settings for your connector type before enabling.

The one principle

Zero Copy has two completely different execution models — Query Federation bills your Snowflake account every time Data Cloud reads, File Federation uses Data Cloud’s own engines against Iceberg storage and doesn’t. Know which one you’re on, because your Snowflake credit bill will. If your Snowflake tables are Iceberg-backed, push toward File Federation. If they’re not, that’s the migration decision hiding inside your “zero copy” architecture.

Related reading: Salesforce Zero Copy connectivity overview · Trailhead: Get Started with Zero Copy Data Federation · Moving to Dynamic Iceberg v3 in Snowflake · Governing the AI Agent: Snowflake CoCo + MCP Security

July 19, 2026
Your First Salesforce Copilot Action : A 5-Step Guide
The era of AI in CRM is here, and its name is Salesforce Copilot. It’s more than just a chatbot that answers questions; in fact, it’s an intelligent assistant designed to take action. But its true power is unlocked when you teach it to perform custom tasks specific to your business.

Ultimately, this guide will walk you through the entire process of building your very first custom Salesforce Copilot action. We’ll create a practical tool that allows a user to summarize a complex support Case and post that summary to Chatter with a single command.

Understanding the Core Concepts of Salesforce Copilot

First, What is a Copilot Action?

A Copilot Action is, in essence, a custom skill you give to your Salesforce Copilot. It connects a user’s natural language request to a specific automation built on the Salesforce platform, usually using a Salesforce Flow.

To see how this works, think of the following sequence:

1. To begin, a user gives a command like, “Summarize this case for me and share an update.”

2. Salesforce Copilot then immediately recognizes the user’s intent.

3. This recognition subsequently triggers the specific Copilot Action you built.

4. Finally, the Flow connected to that action runs all the necessary logic, such as calling Apex, getting the summary, and posting the result to Chatter.

Our Project Goal: The Automated Case Summary Action

Our goal is to build a Salesforce Copilot action that can be triggered from a Case record page. To achieve this, our action will perform three key steps:

1. It will read the details of the current Case.

2. Next, the action will use AI to generate a concise summary.

3. Lastly, it will post that summary to the Case’s Chatter feed for team visibility.

Let’s begin!

Building Your Custom Action, Step-by-Step

Step 1: The Foundation – Create an Invocable Apex Method

Although you can do a lot in Flow, complex logic is often best handled in Apex. Therefore, we’ll start by creating a simple Apex method that takes a Case ID and returns its Subject and Description, which the Flow can then call.

The CaseSummarizer Apex Class
```
// Apex Class: CaseSummarizer
public with sharing class CaseSummarizer {

    // Invocable Method allows this to be called from a Flow
    @InvocableMethod(label='Get Case Details for Summary' description='Returns the subject and description of a given Case ID.')
    public static List<CaseDetails> getCaseDetails(List<Id> caseIds) {
        
        Id caseId = caseIds[0]; // We only expect one ID
        
        Case thisCase = [SELECT Subject, Description FROM Case WHERE Id = :caseId LIMIT 1];
        
        // Prepare the output for the Flow
        CaseDetails details = new CaseDetails();
        details.caseSubject = thisCase.Subject;
        details.caseDescription = thisCase.Description;
        
        return new List<CaseDetails>{ details };
    }

    // A wrapper class to hold the output variables for the Flow
    public class CaseDetails {
        @InvocableVariable(label='Case Subject' description='The subject of the case')
        public String caseSubject;
        
        @InvocableVariable(label='Case Description' description='The description of the case')
        public String caseDescription;
    }
}
```
Step 2: The Automation Engine – Build the Salesforce Flow

After creating the Apex logic, we’ll build an Autolaunched Flow that orchestrates the entire process from start to finish.

Flow Configuration
1. Go to Setup > Flows and create a new Autolaunched Flow.
2. For this purpose, define an input variable: recordId (Text, Available for Input). This, in turn, will receive the Case ID.
3. Add an Action element: Call the getCaseDetails Apex method we just created, passing the recordId as the caseIds input.
4. Store the outputs: Store the caseSubject and caseDescription in new variables within the Flow.
5. Add a “Post to Chatter” Action:
  - Message: This is where we bring in AI. We’ll use a Prompt Template here soon, but for now, you can put placeholder text like {!caseSubject}.
  - Target Name or ID: Set this to {!recordId} to post on the current Case record.
6. Save and activate the Flow (e.g., as “Post Case Summary to Chatter”).
Step 3: Teaching the AI with a Prompt Template

Furthermore, this step tells the LLM how to generate the summary.

Prompt Builder Setup
1. Go to Setup > Prompt Builder.
2. Create a new Prompt Template.
3. For the prompt, write instructions for the AI. Specifically, use merge fields to bring in your Flow variables.
```
You are a helpful support team assistant.
Based on the following Case details, write a concise, bulleted summary to be shared with the internal team on Chatter.

Case Subject: {!caseSubject}
Case Description: {!caseDescription}

Summary:
```
4. Save the prompt (e.g., “Case Summary Prompt”).

Step 4: Connecting Everything with a Copilot Action

Now, this is the crucial step where we tie everything together.

Action Creation
1. Go to Setup > Copilot Actions.
2. Click New Action.
3. Select Salesforce Flow as the action type and choose the Flow you created (“Post Case Summary to Chatter”).
4. Instead of using a plain text value for the “Message” in your Post to Chatter action, select your “Case Summary Prompt” template.
5. Follow the prompts to define the language and behavior. For instance, for the prompt, you can use something like: “Summarize the current case and post it to Chatter.”
6. Activate the Action.
Step 5: Putting Your Copilot Action to the Test

Finally, navigate to any Case record. Open the Salesforce Copilot panel and type your command: “Summarize this case for me.”

Once you issue the command, the magic happens. Specifically, the Copilot will understand your intent, trigger the action, run the Flow, call the Apex, generate the summary using the Prompt Template, and post the final result directly to the Chatter feed on that Case.

Conclusion: The Future of CRM is Action-Oriented

In conclusion, you have successfully built a custom skill for your Salesforce Copilot. This represents a monumental shift from passive data entry to proactive, AI-driven automation. Indeed, by combining the power of Flow, Apex, and the Prompt Builder, you can create sophisticated agents that understand your business and work alongside your team to drive incredible efficiency.
October 17, 2025
Salesforce Agentforce: Complete 2025 Guide & Examples
Autonomous AI Agents That Transform Customer Engagement

Salesforce Agentforce represents the most significant CRM innovation of 2025, marking the shift from generative AI to truly autonomous agents. Unveiled at Dreamforce 2024, Salesforce Agentforce enables businesses to deploy AI agents that work independently, handling customer inquiries, resolving support tickets, and qualifying leads without human intervention. This comprehensive guide explores how enterprises leverage these intelligent agents to revolutionize customer relationships and operational efficiency.

Traditional chatbots require constant supervision and predefined scripts. Salesforce Agentforce changes everything by introducing agents that reason, plan, and execute tasks autonomously across your entire CRM ecosystem.

What Is Salesforce Agentforce?

Salesforce Agentforce is an advanced AI platform that creates autonomous agents capable of performing complex business tasks across sales, service, marketing, and commerce. Unlike traditional automation tools, these agents understand context, make decisions, and take actions based on your company’s data and business rules.

Core Capabilities

The platform enables agents to:
- Resolve customer inquiries autonomously across multiple channels
- Qualify and prioritize leads using predictive analytics
- Generate personalized responses based on customer history
- Execute multi-step workflows without human intervention
- Learn from interactions to improve performance over time
Real-world impact: Companies using Salesforce Agentforce report 58% success rates on simple tasks and 35% on complex multi-step processes, significantly reducing response times and operational costs.

Key Features of Agentforce AI

xGen Sales Model

The xGen Sales AI model enhances predictive analytics for sales teams. It accurately forecasts revenue, prioritizes high-value leads, and provides intelligent recommendations that help close deals faster. Sales representatives receive real-time guidance on which prospects to contact and what messaging will resonate.

xLAM Service Model

Designed for complex service workflows, xLAM automates ticket resolution, manages customer inquiries, and predicts service disruptions before they escalate. The model analyzes historical patterns to prevent issues proactively rather than reactively addressing complaints.

Agent Builder

The low-code Agent Builder empowers business users to create custom agents without extensive technical knowledge. Using natural language descriptions, teams can define agent behaviors, set guardrails, and deploy solutions in days rather than months.

How Agentforce Works with Data Cloud

Salesforce Agentforce leverages Data Cloud to access unified customer data across all touchpoints. This integration is critical because AI agents need comprehensive context to make informed decisions.

Unified Data Access

Agents retrieve information from:
- Customer relationship history
- Purchase patterns and preferences
- Support interaction logs
- Marketing engagement metrics
- Real-time behavioral data
Retrieval Augmented Generation (RAG)

The platform uses RAG technology to extract relevant information from multiple internal systems. This ensures agents provide accurate, contextual responses grounded in your organization’s actual data rather than generic outputs.

Why this matters: 80% of enterprise data is unstructured. Data Cloud harmonizes this information, making it accessible to autonomous agents for better decision-making.

Real-World Use Cases

Use Case 1: Autonomous Customer Service

E-commerce companies deploy service agents that handle common inquiries 24/7. When customers ask about order status, return policies, or product recommendations, agents provide instant, accurate responses by accessing order management systems and customer profiles.

Business impact: Reduces support ticket volume by 40-60% while maintaining customer satisfaction scores.

Use Case 2: Intelligent Lead Qualification

Sales agents automatically engage with website visitors, qualify leads based on predefined criteria, and route high-value prospects to human representatives. The agent asks qualifying questions, scores responses, and updates CRM records in real-time.

Business impact: Sales teams focus on ready-to-buy prospects, increasing conversion rates by 25-35%.

Use Case 3: Proactive Service Management

Service agents monitor system health metrics and customer usage patterns. When potential issues are detected, agents automatically create support tickets, notify relevant teams, and even initiate preventive maintenance workflows.

Business impact: Prevents service disruptions, improving customer retention and reducing emergency support costs.

Getting Started with Agentforce

Step 1: Define Your Use Case

Start with a specific, high-volume process that’s currently manual. Common starting points include:
- Customer inquiry responses
- Lead qualification workflows
- Order status updates
- Appointment scheduling
Step 2: Prepare Your Data

Ensure Data Cloud has access to relevant information sources:
- CRM data (accounts, contacts, opportunities)
- Service Cloud data (cases, knowledge articles)
- Commerce Cloud data (orders, products, inventory)
- External systems (ERP, marketing automation)
Step 3: Build and Train Your Agent

Use Agent Builder to:
1. Describe agent purpose and scope
2. Define decision-making rules
3. Set guardrails and escalation paths
4. Test with sample scenarios
5. Deploy to production with monitoring
Step 4: Monitor and Optimize

Track agent performance using built-in analytics:
- Task completion rates
- Customer satisfaction scores
- Escalation frequency
- Resolution time metrics
Continuously refine agent instructions based on performance data and user feedback.

Best Practices for Implementation

Start Small and Scale

Begin with a single, well-defined use case. Prove value before expanding to additional processes. This approach builds organizational confidence and allows teams to learn agent management incrementally.

Establish Clear Guardrails

Define when agents should escalate to humans:
- Complex negotiations requiring judgment
- Sensitive customer situations
- Requests outside defined scope
- Regulatory compliance scenarios
Maintain Human Oversight

While agents work autonomously, human supervision remains important during early deployments. Review agent decisions, refine instructions, and ensure quality standards are maintained.

Invest in Data Quality

Agent performance depends directly on data accuracy and completeness. Prioritize data cleansing, deduplication, and enrichment initiatives before deploying autonomous agents.

Pricing and Licensing

Salesforce Agentforce pricing follows a conversation-based model:
- Charged per customer interaction
- Volume discounts available
- Enterprise and unlimited editions include base conversations
- Additional conversation packs can be purchased
Organizations should evaluate expected interaction volumes and compare costs against manual handling expenses to calculate ROI.

Integration with Existing Salesforce Tools

Einstein AI Integration

Agentforce builds on Einstein AI capabilities, leveraging existing predictive models and analytics. Organizations with Einstein implementations can extend those investments into autonomous agent scenarios.

Slack Integration

Agents operate within Slack channels, enabling teams to monitor agent activities, intervene when necessary, and maintain visibility into customer interactions directly in collaboration tools.

MuleSoft Connectivity

For enterprises with complex system landscapes, MuleSoft provides pre-built connectors that allow agents to interact with external applications, databases, and legacy systems seamlessly.

Future of Autonomous Agents

Multi-Agent Collaboration

The 2025 roadmap includes enhanced multi-agent orchestration where specialized agents collaborate on complex tasks. For example, a sales agent might work with a finance agent to create custom pricing proposals automatically.

Industry-Specific Agents

Salesforce is developing pre-configured agents for specific industries:
- Financial Services: Compliance checking and risk assessment
- Healthcare: Patient engagement and appointment optimization
- Retail: Inventory management and personalized shopping assistance
- Manufacturing: Supply chain coordination and quality control
Continuous Learning Capabilities

Future releases will enable agents to learn from every interaction, automatically improving responses and decision-making without manual retraining.

Common Challenges and Solutions

Challenge 1: Trust and Adoption

Solution: Start with low-risk use cases, maintain transparency about agent involvement, and demonstrate value through metrics before expanding scope.

Challenge 2: Data Silos

Solution: Implement Data Cloud to unify information across systems, ensuring agents have comprehensive context for decision-making.

Challenge 3: Over-Automation

Solution: Maintain balanced automation by defining clear escalation paths and preserving human touchpoints for high-value or sensitive interactions.

Conclusion: Embracing Autonomous AI

Salesforce Agentforce represents a fundamental shift in how businesses automate customer engagement. By moving beyond simple chatbots to truly autonomous agents, organizations can scale personalized service while reducing operational costs and improving customer satisfaction.

Success requires thoughtful implementation—starting with well-defined use cases, ensuring data quality, and maintaining appropriate human oversight. Companies that adopt this technology strategically will gain significant competitive advantages in efficiency, responsiveness, and customer experience.

The future of CRM automation is autonomous, intelligent, and available now through Salesforce Agentforce. Organizations ready to embrace this transformation should begin planning their agent strategy today.

External Resources
October 17, 2025