Standard Object Oddities in Salesforce

Part 112: Standard Object Oddities in Salesforce

Welcome back to the Salesforce series. This one is going to save you from the kind of pain that only surfaces midway through a project, when everything looks right in your design document but something just will not work the way you expected in the actual org.

Salesforce standard objects are not all created equal. Some support features that others do not. Some have permissions you cannot touch. Some refuse to participate in relationships you would expect them to handle. And the documentation for these inconsistencies is scattered across dozens of help articles, release notes, and Trailhead modules.

This post is your single reference for the most important standard object oddities. If you are an architect designing a solution, a developer building automation, or an admin configuring an org, these are the gotchas you need to have memorized. Let us walk through them category by category.

Standard Objects Where Quick Actions Are Not Available

Quick Actions are one of the most useful tools in the Salesforce declarative toolkit. They let you create records, update fields, log calls, and launch custom components right from a record page or the global action bar. But not every standard object supports them.

The following standard objects do not support object-specific Quick Actions:

• Report and Dashboard — You cannot add Quick Actions to report or dashboard record pages. There is no publisher or action bar on these objects.
• ContentDocument / ContentVersion — Files and content objects do not have a standard action bar. You cannot attach Quick Actions to them.
• User — The User object has extremely limited Quick Action support. You can use global actions on the User record page, but object-specific Quick Actions on the User object are restricted or unavailable depending on the action type.
• RecordType — Setup objects like RecordType do not expose an action framework.
• Many Setup and Configuration objects — Objects like Profile, PermissionSet, Group, and other setup-oriented objects do not support Quick Actions at all.

Workarounds

If you need action-like behavior on these objects, here are your options:

1. Global Actions — Global Quick Actions are available from the utility bar and the global action menu regardless of which object page you are on. If you need to create or update a record from a page that does not support object-specific actions, a global action is your fallback.
2. Custom Lightning Web Components — You can build an LWC that mimics the behavior of a Quick Action and place it directly on the Lightning record page using Lightning App Builder. This is the most flexible approach.
3. Custom Buttons and Links — For simple URL-based actions or JavaScript-based redirects, custom buttons on the page layout still work as an alternative on some objects.
4. Flow Actions — Screen Flows launched from a button or a component can replicate most Quick Action behavior and work on virtually any page.

Gotcha scenario: You design a solution where support agents need to quickly create a follow-up Task from a ContentDocument page. You plan to use a Quick Action. You build it, deploy it, and then discover there is no action bar on ContentDocument. Now you need to pivot to an LWC or a Flow component. That is a mid-sprint redesign you did not budget for.

Standard Objects That Can Have Queues Own Them

Queue ownership is a powerful feature for distributing work. Instead of assigning a record to a specific user, you assign it to a queue, and members of that queue can grab records from the queue list view. But only certain objects support queue ownership.

The standard objects that support Queue ownership are:

Objects That Do NOT Support Queues

Notably, the following common objects cannot be owned by a queue:

• Account — Accounts must always be owned by a user.
• Contact — Contacts must always be owned by a user.
• Opportunity — Opportunities must always be owned by a user. This is a frequent pain point for sales teams that want to distribute deals.
• Task and Event — Activities are always assigned to a user. You cannot route tasks to a queue.
• Campaign — Campaigns require a user owner.

Workarounds

• Assignment Rules — For Lead and Case, assignment rules provide automatic queue routing based on criteria. This is the most admin-friendly approach.
• Flow-Based Round Robin — For objects that do not support queues (like Opportunity), you can build a Flow that cycles through a list of users stored in a custom metadata type or custom setting to simulate queue behavior.
• Custom Lookup Field — You can create a lookup field to a queue-like custom object to track which team should work a record, even if the OwnerId field cannot point to a queue.

Gotcha scenario: A stakeholder asks you to build a queue-based assignment system for Opportunities. You spend time designing the queue structure and assignment rules, only to discover that Opportunity does not support queue ownership at all. Now you need a completely different approach, like a custom round-robin Flow or a third-party app.

Standard Objects That Cannot Have Their CRUD Updated in Profiles or Permission Sets

This one catches administrators off guard more than almost anything else. Some standard objects have fixed CRUD (Create, Read, Update, Delete) permissions that you simply cannot change through Profiles or Permission Sets.

Here are the key offenders:

Workarounds

• System Permissions — Look for dedicated system permissions like “Manage Users,” “Manage Price Books,” or “Manage Custom Metadata” that control access to these objects.
• Org-Wide Settings — Some controls live in Setup under specific feature areas. Activity deletion settings, for example, are under Activity Settings.
• Custom Permissions — If you need to restrict access to specific functionality around these objects, consider using custom permissions checked in Apex or Flow logic.

Gotcha scenario: You are building a delegated admin model. You create a Permission Set that should let team leads delete Tasks assigned to their team. You go to the Task object permissions and discover there is no Delete checkbox. You search the documentation and eventually find the “Allow Users to Delete Activities” org-wide toggle buried in Activity Settings. But that toggle is all-or-nothing — you cannot scope it to just team leads. Now you need a different approach entirely.

Standard Objects That Cannot Be Used in a Lookup Relationship Field

When you create a custom Lookup Relationship field, you pick a target (parent) object. Most standard objects can serve as lookup targets, but some cannot.

Objects that cannot be the target of a custom Lookup Relationship include:

• Attachments — You cannot create a lookup to the Attachment object.
• Notes — The legacy Note object is not available as a lookup target.
• ContentNote and ContentDocument — Content objects are not available as standard lookup targets. You interact with them through ContentDocumentLink junction records instead.
• ActivityHistory / OpenActivity — These are aggregate relationship objects, not true queryable objects. You cannot look up to them.
• FeedItem / FeedComment — Chatter feed objects do not support custom lookups.
• EmailMessage — While it is a real object, you cannot create a custom lookup field pointing to EmailMessage.
• Many platform and setup objects — Objects like ApexClass, ApexTrigger, FlowDefinition, Profile, and PermissionSet are not available as lookup targets in custom fields.

Why This Matters

If your design calls for a custom object that references one of these restricted objects, you need an alternative. Options include:

1. Store the record Id in a Text field — Not ideal because you lose referential integrity, but it works for reporting and navigation with a formula-based URL.
2. Use Junction Objects — For content relationships, ContentDocumentLink already serves as a junction. Work with the existing data model instead of fighting it.
3. Polymorphic Lookups (WhoId / WhatId) — Some standard fields like WhoId and WhatId on Task and Event are polymorphic lookups that can point to multiple object types. You cannot create custom polymorphic lookups declaratively, but understanding how the standard ones work helps you design around limitations.

Gotcha scenario: You want to build a custom “Document Review” object with a lookup to ContentDocument so reviewers can directly reference the file. You discover that ContentDocument is not an available lookup target. Instead, you have to store the ContentDocumentId in a text field or write Apex to manage the relationship through ContentDocumentLink records.

Standard Objects That Can Use Dynamic Forms

Dynamic Forms is a Lightning App Builder feature that lets you place individual fields and field sections anywhere on a record page, with component visibility rules that control when they appear. It is a major step forward from the rigidity of page layouts.

However, Dynamic Forms is not available on all standard objects. Salesforce has been rolling out support incrementally over many releases.

Objects That Support Dynamic Forms

As of recent releases, Dynamic Forms is supported on:

• Account
• Contact
• Opportunity
• Lead
• Case
• Campaign
• Order
• Product
• Price Book
• All Custom Objects (Custom objects were the first to get Dynamic Forms support)
• Solutions
• Contract
• Assets

Objects That Do NOT Yet Support Dynamic Forms

• Task and Event — Activities do not support Dynamic Forms. You are stuck with page layouts.
• Quote — Quote pages do not support Dynamic Forms.
• Person Account — Person Accounts have partial support. The Account portion works, but the Contact portion has limitations.
• Knowledge — Knowledge articles do not support Dynamic Forms.
• Many less common standard objects — Objects like WorkOrder, ServiceAppointment, and other Field Service objects may have limited or no Dynamic Forms support depending on the release.

Why Dynamic Forms Matters for Architecture

Dynamic Forms changes how you think about page layouts. Instead of creating multiple page layouts for different record types or profiles, you can use a single Lightning record page with visibility rules that conditionally show fields. This means:

• Fewer page layouts to maintain
• More granular control over field visibility
• Better user experience with contextually relevant fields
• Reduced admin overhead when requirements change

If your solution relies on Dynamic Forms for conditional field visibility and your target object does not support it, you need fallback strategies like multiple page layouts assigned by record type, or custom LWC components that handle the conditional logic.

Gotcha scenario: You design a streamlined Case page using Dynamic Forms with conditional sections that show different fields based on the case origin. Beautiful solution. Then the stakeholder asks you to do the same thing for Tasks. You discover Dynamic Forms is not supported on Task, and now you need three different page layouts instead of one dynamic page.

Why Knowing These Oddities Matters for Architecture Decisions

These are not trivia questions. These are the kinds of details that determine whether a design will actually work once you start building.

When you are creating a solution design document, you need to validate every assumption against the actual platform capabilities. The common failure pattern looks like this:

1. Architect designs a solution based on how things work for custom objects or the most common standard objects.
2. The team starts building.
3. Midway through, someone discovers that the target standard object does not support a key feature the design depends on.
4. The team scrambles to redesign, eating into the timeline and budget.

Here is how to avoid that:

• Always prototype key interactions early. Before committing to a design, build a quick proof of concept in a dev org. Try creating the Quick Action, the queue, the lookup, and the Dynamic Form. Verify that it works on your target object.
• Keep a reference sheet. Bookmark this post or build your own internal wiki page that tracks which standard objects support which features. Update it with every Salesforce release.
• Read the release notes. Salesforce expands standard object support for features like Dynamic Forms in almost every release. What does not work today might work in the next release.
• Design for fallbacks. If a feature is critical to your solution and you are not 100 percent sure the target object supports it, have a Plan B ready. Know what the workaround is before you need it.

Section Notes

This section covered the inconsistencies and limitations of Salesforce standard objects that trip up even experienced professionals. The key takeaways:

• Quick Actions are not available on all standard objects. Use global actions, LWC, or Flows as alternatives.
• Queue ownership is limited to Case, Lead, Order, ServiceContract, Knowledge, and a few others. Common objects like Account, Contact, and Opportunity do not support queues.
• CRUD permissions on some standard objects like User, Task, and Product cannot be managed through normal Profile or Permission Set toggles. Look for dedicated system permissions and org-wide settings instead.
• Lookup relationships cannot target many platform objects like ContentDocument, Attachment, or EmailMessage. Use text fields with stored IDs or work with existing junction objects.
• Dynamic Forms support has been expanding but is still not available on all standard objects. Task, Event, Quote, and Knowledge are among those that do not yet support it.

The overarching lesson: never assume that a feature that works on one standard object will work on another. Validate early, design for fallbacks, and keep your knowledge current with every release. In the next section, we will continue exploring Salesforce architecture patterns that help you build solutions that work within these platform realities.