WhoId vs WhatId: Salesforce Record IDs Explained

If you have ever pulled Salesforce Activity data into a report, tried to build automation around tasks, or debug a weird “why is this Activity attached there?” issue, you have probably hit the same fork in the road: WhoId vs WhatId. They look similar, they sit next to each other on Task and Event, and they both “link” an Activity to something. But they do very different jobs, and mixing them up creates messy reporting, broken attribution, and confusing timelines.

The practical difference is simple: WhoId points to a person, and WhatId points to a non-person record. The nuance is where most implementations go sideways.

Where WhoId and WhatId live (and why it matters)

In Salesforce, Tasks and Events are Activities. Activities are designed to be related to both:

• a human you are engaging with (lead/contact)
• a thing you are working on (account/opportunity/case/custom object)

Salesforce enables that split by storing two separate lookups on the Activity record: WhoId and WhatId, described clearly in this breakdown of WhoId vs WhatId in Salesforce Activities.

In practice, that means you can log “Call with Maria (Contact) about Renewal Opportunity” in a way that supports both relationship context (Maria) and business context (Renewal Opp).

WhoId: the “who” side is a Lead or Contact

What WhoId can reference

WhoId is used when the Activity relates to a person record. In Salesforce terms, that person is typically:

• Lead
• Contact

That is why you will often see the field label “Name” on Task/Event layouts. Under the hood, that “Name” field maps to WhoId when the selected record is a Lead or Contact, as clarified in this Salesforce Stack Exchange explanation of how WhoId maps to Leads and Contacts.

What you get when you use WhoId correctly

When WhoId is set properly, you unlock the people-centric views your users expect:

• Activities show up cleanly on the Lead or Contact timeline.
• Sales reps can open a Contact and see calls, emails, and meetings without hunting across Opportunities.
• Marketing and RevOps can segment engagement by persona or contact role more reliably.

WhatId: the “what” side is a business record (not a person)

What WhatId can reference

WhatId points to the related object that is not a person record. Common examples include:

• Account
• Opportunity
• Case
• Campaign
• Custom objects (depending on configuration)

This pattern is summarized in a concise way in this WhoId vs WhatId walkthrough focused on Activity relationships.

Why WhatId drives pipeline attribution and operational reporting

If your Activities are only tied to WhoId and not WhatId, you lose a lot of business context:

• Opportunity-level activity metrics become unreliable.
• Case timelines miss important calls and follow-ups.
• Account teams cannot easily see “everything happening for this customer” without jumping across Contacts.

In other words, WhoId supports relationship history. WhatId supports operational and revenue history.

How Salesforce chooses between WhoId and WhatId in the UI

Salesforce makes this confusing because the UI labels do not always say “WhoId” or “WhatId”. Instead, users typically see fields like:

• Name (often the Lead/Contact, aka WhoId)
• Related To (often the Opportunity/Account/Case, aka WhatId)

That naming convention is one of the root causes of bad data. Users think “Name” means the Account name, or they fill “Related To” and skip the person entirely, which later breaks contact-level engagement reporting. The UI behavior and mapping is discussed in the SalesforceBen explanation of the two Activity relationships.

Practical scenarios: what goes where (real-world patterns)

Sales call about a deal

Scenario: Rep calls a stakeholder to discuss pricing on an open Opportunity.

• WhoId: the stakeholder (Contact)
• WhatId: the Opportunity

This is the ideal pattern for accurate opportunity activity rollups and a clean contact timeline. The “person vs thing” intent is reinforced in the Stack Exchange thread describing WhoId as Lead/Contact and WhatId as another object.

Support follow-up

Scenario: Support agent schedules a follow-up meeting with a customer contact about a Case.

• WhoId: the customer Contact
• WhatId: the Case

This keeps the Case timeline complete while preserving the relationship context for anyone viewing the Contact record.

Account planning meeting with multiple attendees

Scenario: CSM runs a quarterly business review tied to an Account, with several Contacts invited.

• WhatId: Account (or a custom “Customer Plan” object if you use one)
• WhoId: depends on how you log it; you may attach the Event to a primary Contact (WhoId) and use invitees for the rest

The key is to avoid losing the “what” context when multiple people are involved.

Common mistakes that quietly break reporting

Logging Activities only to the Contact (WhoId) and forgetting the Opportunity (WhatId)

This is the fastest way to undercount sales effort at the deal level. Your CRM might show a busy Contact timeline, but pipeline reports look like “no one is working the deal.”

Logging Activities only to the Opportunity (WhatId) and leaving WhoId blank

This creates the opposite problem: the deal looks active, but contact engagement is fragmented. Reps open the Contact record and see a blank history, then assume “no one has touched this person.”

Assuming WhoId can point to Accounts

It cannot. Accounts are not people records. If you want an Activity related to an Account, that is a WhatId relationship, consistent with the “Who is a Lead/Contact, What is another object” distinction in the OddEven Infotech Activity reference.

Implementation tips that make WhoId vs WhatId behave predictably

Standardize what “good” looks like for your org

Define a simple rule your teams can remember:

• If there is a specific person involved, set WhoId.
• If the activity is about a deal, case, account, or process record, set WhatId.

This aligns with the field intent described in SalesforceBen’s practical overview.

Build validation and training around the two-field model

You do not need to over-engineer this. Two lightweight fixes go a long way:

• Page layout guidance: make “Name” and “Related To” prominent for Activities.
• Reporting checks: create views that highlight Activities missing WhoId or WhatId where your process expects both.

Troubleshoot by thinking “person timeline vs record timeline”

When users say, “My call is not showing up,” ask:

• Are they looking at the Contact/Lead? That is WhoId territory.
• Are they looking at the Opportunity/Case/Account? That is WhatId territory.

That mental model maps directly to how Salesforce stores and displays Activities, as described in the Stack Exchange clarification of each field’s relationship type.

Share With Others