Get in Touch

Tag: Decision Framework

  • Agentforce in a contact centre: where it helps the agent, and where it should stay out of the way

    A support agent picks up a call about a failed order. Before they’ve said a word, the case history, the customer’s last three interactions and a draft summary of the account are already sitting on screen. That’s Agentforce doing its job well: invisible, fast, and out of the customer’s way. Ten minutes later the same customer is angry about a refund policy exception, and the agent needs to read the room, bend a rule slightly, and say something that sounds human. That’s a different job entirely, and it’s not one Agentforce should be doing.

    I’ve spent years inside contact-centre Service Cloud orgs, and the pattern with Agentforce is becoming clear fast: the technology is genuinely good at a specific band of work, and genuinely bad at the work either side of that band. Knowing where that line sits matters more than any feature list Salesforce ships this year.

    Where Agentforce earns its place

    The strongest use cases I’ve seen all share one trait: they’re information-retrieval and drafting problems, not judgment problems.

    Summarising before the agent needs to ask

    Case summarisation is the easiest win in the whole platform. An agent opening a case with eleven prior interactions, three transfers and a product return doesn’t need to read all of that. They need the three facts that matter right now. Agentforce reading case history and surfacing a two-line summary saves real seconds on every single call, and seconds compound across thousands of calls a week.

    First-draft replies on routine requests

    Password resets, order status, standard policy questions: these have one correct answer and no emotional complexity. Letting Agentforce draft the reply and having the agent review and send it is faster than typing from scratch, and it’s lower risk than it sounds, because the agent is still the one hitting send.

    Routing and triage

    Classifying an inbound case by intent, urgency and the right queue is exactly the kind of pattern-matching large language models are built for. I’ve watched Omni-Channel routing improve meaningfully once case classification stopped depending on a customer picking the right dropdown option on a web form.

    Where it should stay out of the way

    The failure cases I’ve seen cluster around three things: emotional nuance, irreversible actions, and genuine edge cases the model has never seen framed quite that way.

    Anything with an angry or vulnerable customer

    An agent can hear tone shift in someone’s voice and adjust. A model reading transcript text is working from a much thinner signal. Handing de-escalation, retention conversations, or anything touching a customer in genuine distress to an autonomous agent is a bad trade even when the model gets the facts right, because the facts were never the hard part.

    Actions that can’t be undone

    Refunds above a threshold, account closures, data deletion requests: give Agentforce a narrow, well-tested action for these and it’ll happily execute it exactly as scoped. The risk isn’t the model being wrong occasionally. It’s that “occasionally” compounds fast when the action is irreversible and the volume is high. I treat any Apex action tied to money or data loss as something a human approves, full stop, no matter how good the surrounding prompt is.

    The exception that breaks the pattern

    Every contact centre has cases that don’t fit the normal shape: the customer who’s a VIP but isn’t flagged as one, the policy exception that was agreed on a call six months ago and never got written down, the integration that silently failed last Tuesday and left three systems disagreeing about the truth. Agentforce has no way to know what it doesn’t know. A human agent, at minimum, knows when something feels off.

    A rough framework for the line

    When I’m scoping where Agentforce should sit in a Service Cloud build, I ask three questions about the task:

    • Is there a single correct answer, or does the right answer depend on reading a person?
    • Can the action be reversed cheaply if the model gets it wrong?
    • Has this exact shape of request happened often enough that the model has real pattern density to draw on?

    Three yeses, and Agentforce can probably run with real autonomy. Two yeses, give it a supporting role with a human in the loop. One or zero, keep it out of the workflow entirely and spend the budget somewhere else.

    What this means for the build

    Practically, this changes how I scope Agentforce actions. I design the narrowest possible action for each task rather than one broad “handle the case” agent. A tight action that looks up order status is easy to test, easy to monitor, and easy to trust. A broad action that can also issue refunds, update addresses and escalate cases is none of those things, even if it demos beautifully.

    It also changes where I put the guardrails. Input validation on every Apex action an agent can call isn’t optional, because the agent will eventually call it with something you didn’t anticipate. And every action above a certain blast radius gets a human approval step before anything executes, not because I distrust the model specifically, but because that’s the same discipline I’d apply to any automation touching customer money or customer trust.

    None of this is an argument against Agentforce in a contact centre. It’s an argument for being precise about which parts of the job it’s actually solving. The agents who do this well in six months won’t be the ones who gave Agentforce the most access. They’ll be the ones who worked out, task by task, exactly where the model was reliable and designed everything else around a human doing what humans are still better at.

  • Zero Copy and Data Cloud: when you actually need it, and when a sync job still wins

    Every Data Cloud conversation I’ve had in the last year eventually turns to Zero Copy. Someone read a blog post, saw a demo, and now wants to know why the team is still running nightly batch jobs to move data into Salesforce when Salesforce says you don’t have to copy anything at all. It’s a fair question. The answer is less exciting than the marketing: Zero Copy is the right tool for a narrow set of problems, and a genuinely bad fit for most of the integration work a typical org still needs.

    I’ll say the quiet part up front. Zero Copy doesn’t mean “no copying happens anywhere.” It means Data Cloud can query data sitting in an external system, typically a data warehouse like Snowflake, Databricks, Redshift or BigQuery, without physically ingesting it into Data Cloud’s own storage first. Federated access, not teleportation. The data still lives where it lived. Salesforce reaches out and reads it on demand, or through a virtualised connection, instead of pulling a copy in and storing it locally.

    What Zero Copy is actually solving

    Three real problems, and they’re the ones worth checking your org against before you touch a connector.

    Storage and duplication cost

    Every record you ingest into Data Cloud takes up space and needs to be kept in sync. If your warehouse already holds ten years of transaction history and you only need the last 90 days visible inside a Salesforce flow, ingesting the full history is wasteful twice over: you’re paying for storage you don’t need, and you’re building a pipeline to keep a copy fresh that nobody asked for.

    Freshness

    Batch sync jobs run on a schedule. Hourly, nightly, whatever the pipeline was built for. If a contact-centre agent needs to see a customer’s current loyalty tier and that tier updates in near real time in the warehouse, a four-hour-old copy in Data Cloud is wrong exactly when it matters. Zero Copy queries the source directly, so the answer reflects what the warehouse has right now, not what it had at the last sync.

    Governance and single source of truth

    Some organisations have a hard rule, often from a previous audit finding, that customer financial or health data cannot be duplicated outside its system of record. Compliance teams like fewer copies, not more. Zero Copy lets Salesforce reference that data for a specific use case without creating another place it has to be secured, retained and eventually deleted.

    Where a sync job still wins

    This is the part that gets skipped in the demos. A traditional ingestion or sync pattern beats Zero Copy in a lot of ordinary situations, and pretending otherwise causes real problems six months later.

    Query volume and latency

    Federated queries go over the network to the source system, every time. If you’re building something that needs to evaluate thousands of records per second, inside a real-time decisioning flow or an Agentforce topic that fires on every page load, round-tripping to an external warehouse for each lookup adds latency you can’t always absorb. Ingested data sitting in Data Cloud’s own storage is fast because it’s local. That’s not a small detail. I’ve seen a well-intentioned Zero Copy design get quietly reverted after performance testing showed response times that were fine in a demo with ten records and unacceptable with ten thousand.

    Transformation needs

    If the data needs real shaping before it’s useful, identity resolution, calculated fields, harmonisation across multiple source systems, a batch pipeline that transforms on the way in is usually simpler to build, test and debug than trying to push that logic into a live federated query. Zero Copy is a read path. It’s not where you want to be doing heavy lifting.

    Source system availability

    A sync job decouples Salesforce from the warehouse’s uptime. If the warehouse has maintenance windows, rate limits, or occasional outages, a Zero Copy dependency means your Salesforce experience goes down with it. A local copy keeps functioning even when the source is briefly unreachable. For anything customer-facing, that resilience is worth more than the storage you save.

    Cost at scale, the other direction

    Zero Copy isn’t free. Federated queries against a warehouse usually cost compute on the warehouse side, and that cost scales with how often Salesforce asks. A high-frequency use case can end up more expensive querying live than it would have been ingesting a well-scoped subset once a day. Nobody puts that in the slide deck.

    A decision framework that actually holds up

    Before picking a pattern, I ask four questions, roughly in this order.

    • How often does this data actually change, and does the use case genuinely need to see it the moment it changes, or is “accurate as of last night” good enough?
    • What’s the query pattern: occasional lookups during a case or interaction, or high-frequency reads across a large population?
    • Does the data need transformation, joining or harmonisation before it’s usable, or is it already clean and query-ready at the source?
    • Is there a governance constraint that actively prohibits a second copy, versus a preference for “less duplication is nicer”?

    If the honest answers are: rarely changes, low query volume, minimal transformation, and no hard governance block, Zero Copy might genuinely save you a pipeline. If any one of those tips the other way, especially the query volume question, a conventional sync is probably the safer build, and it’s the one your team already knows how to monitor and fix at 2am when something breaks.

    What I tell clients

    Zero Copy earns a place in an architecture when it removes a specific, named pain: a duplication rule from compliance, a freshness gap that’s actually been reported as a problem, or a dataset so large that ingesting it was never going to be practical. It’s not a default. I’ve started treating it the way I treat any other integration pattern choice: pick it because the requirements point there, not because it’s the pattern with the most momentum in the ecosystem this quarter. A sync job that’s boring, well-tested and runs every night without surprises is still, for most orgs, the right answer most of the time.