Skip to main content

SF-0200 · Scenario · Medium

Blocks in a joined report must be based on related salesforce objects?

✓ Verified by Vikas Singhal · Last reviewed 5/17/2026 · Updated for Spring '26

No. Blocks in a Joined Report do not have to be based on related Salesforce objects. The “join” in Joined Report is not a foreign-key join like SQL — it’s a side-by-side rendering of independent blocks that share a common grouping or filter. The blocks can be drawn from entirely unrelated report types.

What the “join” actually means

Joined Reports get their name from blocks running in the same viewer with optionally shared groupings and filters — not from any relational join across object trees. Each block is independently queried, and results are assembled visually.

TermMeaning
JoinedThe visual layout — blocks share a report page
Common groupingThe block-spanning dimension (e.g. group all blocks by Account)
Shared filterReport-wide filter applies to all blocks
Per-block filterBlock has its own filters too

Examples of unrelated blocks

Block 1: Opportunities by Owner
Block 2: Cases by Owner
Block 3: Activities by Owner

Opportunities, Cases, and Activities are different objects. Their report types aren’t related to each other. The only thing linking them is the common grouping by Owner (each block groups on the same field name with the same values).

Block 1: Marketing — Leads by Source
Block 2: Sales — Opportunities by Stage
Block 3: Service — Cases by Status

Three totally different functional areas, three different objects, no foreign key between them. Joined report works fine.

When blocks should share a relationship

While not required, blocks usually become more useful when they share a dimension:

  • All grouped by Account.Name → see all sub-records per account
  • All grouped by OwnerId → see all activity per rep
  • All grouped by CALENDAR_MONTH(CreatedDate) → see all activity per month

That shared grouping lets you read across blocks horizontally.

What blocks can’t share automatically

  • Cross-block filters that traverse foreign keys — there’s no foreign-key join. If you want to show “only Cases where Account has more than $1M revenue”, you filter Cases independently on Account.Revenue.
  • Bucket fields — buckets don’t work in Joined.
  • Cross filters (the “Accounts with Cases” type) — not available in Joined format.

Practical pattern: customer 360

A real-world joined report:

Common grouping: Account.Name (all blocks)
Common filter: Account.Type = "Customer"

Block 1: Account info (Name, Industry, Owner, Status)
Block 2: Open Opportunities by Stage
Block 3: Open Cases by Priority
Block 4: Recent Activities by Type
Block 5: Quotes by Status

Each block uses a different report type. None share a foreign key to the others. The viewer reads each Account’s section across all five blocks vertically. That’s the joined report’s strength.

Common follow-ups

  • Can blocks share fields if the objects aren’t related? — Only via a common grouping field with the same values (e.g. OwnerId exists on many objects).
  • Why doesn’t Salesforce restrict block report types? — Because the value of joined reports is precisely showing disparate data side by side.
  • Performance cost? — Each block is a separate query — keep block count low and filters tight.

Verified against: Salesforce Help — Joined Reports. Last reviewed 2026-05-17 for Spring ‘26.