Get in Touch

Category: Salesforce

  • Why “more clicks” is a business problem, not a UX detail

    Somewhere in most Salesforce orgs there’s a case, an order, or a new customer record that takes twenty-something clicks to create when it should take five. Nobody put it there on purpose. It built up one validation rule, one extra screen, one “just add a field” request at a time, and now it’s baked into how the team works every single day.

    Most people treat that as a UX complaint. Someone finds it mildly annoying, mentions it in a retro, and it gets logged as a “nice to have” enhancement that never survives the backlog cut. That framing is wrong. Click count isn’t a cosmetic detail. It’s a direct line item on your operating cost, and it compounds in ways that don’t show up until someone actually goes looking.

    Clicks are a proxy for time, and time is the real metric

    A click on its own means nothing. What it represents is a decision point, a page load, a chance to misread a field, or a moment where an agent has to stop and think instead of act. Multiply one extra click across a few hundred transactions a day and you’re not looking at a minor inconvenience anymore. You’re looking at minutes of average handle time, a number every contact centre already tracks obsessively.

    I worked on a customer-acquisition process that ran to 96 clicks from first contact to a completed record. Nobody had measured it that way before. Once we did, it stopped being a UX conversation and turned into a resourcing conversation, because at that click count, headcount planning was quietly built around a broken process. We got it down to 17. Same data captured, same compliance requirements met, a fraction of the effort. That’s not a UI polish story. That’s a story about how many people you need on shift.

    Where the extra clicks actually come from

    In practice, click bloat rarely comes from one obvious villain. It’s usually four or five small things stacked on top of each other:

    • Page layouts that grew organically, with fields from three different projects sitting on one screen in no particular order
    • Record types and page layout assignments that force an extra selection screen nobody actually needs
    • Validation rules written to catch an edge case that happens twice a year, applied to every single record anyway
    • Related lists and components left on a page because removing them felt risky, not because anyone still uses them
    • Manual steps that exist because a Flow or Quick Action was never built, so someone just clicks through it by hand

    None of these shows up as one big design flaw. They show up as a slow accumulation, and that’s exactly why they survive so long. Nobody’s incentivised to fix a two-click problem. Fixing a twenty-click problem is a different conversation entirely, and it’s one worth having on purpose rather than by accident.

    Why leadership should care about a number that sounds like an engineering detail

    Click count converts cleanly into numbers leadership already tracks. Average handle time. Cost per case. Time to productivity for a new hire. Error rate on manual data entry. None of those are Salesforce metrics. They’re business metrics, and click count is one of the few technical details that maps onto them directly.

    If you’re pitching an enhancement to leadership and the pitch is “the screen looks cleaner” or “it’s more intuitive,” you’ll lose that argument nine times out of ten, and honestly, you should lose it. Those aren’t reasons to spend engineering time. But “this cuts average handle time by 40 seconds across 800 daily interactions” is a business case, not a design preference, and it tends to get funded.

    How to actually find where the clicks are hiding

    Auditing this doesn’t require anything fancy. Walk through the three or four highest-volume processes in your org, start to finish, as if you were the agent doing it for the two-hundredth time that day. Count every click, every page load, every field you have to scroll to find. Write the number down.

    Then ask, for each step, whether it exists because the business genuinely needs that information captured at that point, or because it’s just always been there. You’ll find both. Don’t assume which is which until you’ve asked someone who runs the process daily, because the answer is often surprising. A field that looks pointless to an architect might be the one thing compliance actually checks every quarter.

    A short framework that holds up in practice

    For any screen or step in a high-volume process, ask three questions. Does this need a human decision, or can a default or automation make the call instead? Does this need to happen right now, or can it happen later without breaking anything downstream? Does this need its own screen, or can it live on the screen the agent is already looking at?

    Most click reduction work isn’t clever. It’s disciplined. Collapse record types where the business rule doesn’t actually require a fork. Push validation logic into Flow so it only fires when the edge case is real, not on every save. Pull related information onto the main record page with a component instead of forcing a click into a related list. None of it needs new technology. It needs someone willing to count the clicks first and argue the business case second.

    The part that gets missed

    Reducing clicks isn’t a one-off project you finish and move on from. Every new field, every new validation rule, every “small” enhancement request adds clicks back in unless someone’s watching for it. That’s the actual discipline: treating click count as a metric you monitor over time, the same way you’d monitor system performance or data quality, rather than a problem you solve once during a big platform refresh.

    The orgs that stay lean aren’t the ones that never had click bloat. They’re the ones that built a habit of asking, every time something gets added to a screen, whether it earns the extra click it’s about to cost everyone who runs that process for years afterward.

  • Why Your Data Cloud Unified Profiles Might Be Duplicating Silently (And How to Fix It)

    If you’ve been running Salesforce Data Cloud for a while, you’ve probably hit this: identity resolution looked fine when you set it up, match rates seemed healthy, and then months later someone notices two “Unified Profiles” for the same customer — one with the old email, one with the new one. No error. No alert. Just quietly wrong data feeding into your segments and activations.

    This is one of those issues that’s small enough to get missed in QA, but expensive enough to erode trust in the whole Data Cloud investment once someone in marketing or sales spots it.

    What’s Actually Happening

    Data Cloud’s identity resolution runs on match and reconciliation rules that you define once, typically during initial setup. Here’s the part that catches people out: when you change a match rule after go-live, it does not automatically reprocess your existing, already-resolved Unified Profiles.

    Identity resolution in Data Cloud is incremental by design — new and changed source records get evaluated against the current ruleset as they come in. But records that were already unified under an older version of your match rules just sit there. They were correct under the old logic, so nothing re-triggers them.

    Common scenario:

    • You launch with match rules based on email address.
    • Six months in, you add a phone-number-based match rule to catch more matches (a very normal, well-intentioned change).
    • New records now match correctly on phone.
    • Existing profiles that could now match under the new rule — but didn’t exist yet when the rule changed — stay split into separate Unified Profiles.
    • A customer who updated their email address now has two profiles: their historical one and a new one, both technically “resolved” but never merged.

    Nothing in the UI tells you this happened. Data stream status shows healthy. Reconciliation jobs report success. The only symptom is downstream: inflated audience counts, duplicate marketing sends, or a service rep pulling up an incomplete history.

    Why It’s Easy to Miss

    • Data Cloud shows identity resolution job success/failure, not whether a rule change affected historical data.
    • Match rate metrics are calculated going forward, not against your full historical base.
    • There’s no built-in “reprocess all profiles against current rules” button that runs automatically after a rule edit — it has to be deliberately triggered.
    • Teams often treat identity resolution as “set once” configuration rather than something that needs a change-management process.

    How to Fix It

    1. Force a full reprocessing run after any match/reconciliation rule change. After editing rules, manually trigger identity resolution to reprocess against the entire population, not just new records. This is a deliberate action in Data Cloud — don’t assume it happens on save.

    2. Baseline your Unified Profile count before and after rule changes. Before changing a rule, export or note your current Unified Individual/Profile counts per key segment. After reprocessing, compare. A meaningful drop in profile count usually means more merging happened (good); a count that doesn’t move at all after adding a rule that should catch more matches is a red flag that reprocessing didn’t actually run.

    3. Build a recurring duplicate-detection check, not a one-time audit. Set up a periodic query (via Data Cloud’s Query API or a scheduled report) that looks for individuals sharing a strong identifier (verified email, phone, loyalty ID) across two different Unified Profile IDs. Run it monthly, not just after known rule changes — someone may edit a rule without realizing its downstream impact.

    4. Document match/reconciliation rule changes like schema changes. Any identity resolution rule edit should go through the same change log/approval you’d use for a data model change. Include a mandatory “reprocess triggered: yes/no” field. This alone prevents most of the silent-drift cases.

    5. Communicate the limitation to stakeholders early. When you first configure identity resolution, tell the business teams explicitly: “changing match rules later requires a reprocessing step, and we will schedule that deliberately.” This avoids the awkward conversation six months later when someone finds duplicates and assumes the platform is broken.

    The Bigger Lesson

    This isn’t a bug — it’s a design decision that makes sense for performance at scale (Data Cloud isn’t going to re-evaluate your entire customer base on every rule tweak automatically). But it’s a decision that isn’t well surfaced to admins, and the cost of not knowing about it is duplicate profiles that quietly undermine the “single customer view” that’s the entire point of the platform.

    If you’re running Data Cloud, the practical takeaway is simple: treat identity resolution rule changes as an event that requires a follow-up action, add a recurring duplicate check to your monitoring, and don’t assume “job succeeded” means “your data is fully unified.”

    Have you run into this on your own Data Cloud implementation? Reach out — always keen to compare notes on the small issues that don’t make it into the official docs.