#Experience Cloud55 discutindo

Hi Andrea — you've hit a real boundary. Short version: Salesforce CMS does not full-text-index the text inside a PDF's binary. The CMS content search / content-search-api indexes the content item's fields (title, metadata, body/content nodes), not the bytes inside an attached PDF — which is exactly why your title search works but a content search comes back empty. There's no OOTB CMS setting to flip for "search inside PDF content." 

Where Salesforce does search inside PDFs OOTB: Salesforce Files (ContentVersion). Global / SOSL search extracts and indexes the text content of uploaded files, including PDFs (within size limits), so a SOSL query over ContentVersion matches on text inside the PDF. So the native "search inside a PDF" capability exists — it just lives on Files, not on CMS content. 

Practical options for your custom component: 

1. Store or expose the PDFs as Salesforce Files (ContentVersion) and have your component run SOSL against ContentVersion — you get inside-the-PDF matching for free (subject to the documented file-content index limits). Least-effort native route. 

2. Extract the text at ingest and make it searchable: run the PDF through a text-extraction/OCR step (an Apex PDF library, or a Flow/Apex HTTP callout to an extraction or OCR service) when the document is added, and store the extracted text in a searchable field — on the CMS content or a related custom object your component queries. This is the usual pattern when the file must stay in CMS but you still need full-text search. 

3. If you're on an Industries cloud, look at Smart Content Search — it is designed to search within document content, but it's license/cloud-specific, so confirm it applies to your org. 

Net: no OOTB CMS "search inside PDF," but Files + SOSL gives you native in-PDF search, and text-extraction-on-ingest is the standard workaround when the content needs to stay in CMS. 

Ref: How search indexes and finds text (including within files):

@Vijay Sadhu

, 

Check the official article below; it will help you, 

Hi @Satendar Yadav

Could you please try including the NetworkId of the Experience Cloud site in the ContentVersion POST request body?  

Thanks!

Hey @Roopa Sharma

If user A wants

emails they are the approver for on holiday, set it to "Only if I am an approver"  

If user A wants ALL emails whether they are an approver or a delegated approver, set it to "If I am an approver or delegated approver" 

Thank you for the response @ENIO ANSELMO DE SOUZA

As mentioned, we are not retiring Chatter, but instead are encouraging orgs to use Slack's Salesforce Channels for record collaboration in place of Chatter.  Experience Cloud specifically has some unique usage of Chatter, such as the forum's use case where an unauthenticated user is able to read Chatter posts, and it is unknown if or when Slack would support this use case, so we plan to continue supporting Chatter. 

Also mentioned, if you're looking into building an integration with Chatter, you may consider if a Slack may be a better fit, or else build in a way which could enable moving to Slack at a later date if desired.

Hi Bharath, 

Both of these are common limitations with Sharing Sets once you get beyond simple one-hop, single-object visibility. Here's the breakdown for each: 

1. Dealer visibility issue 

The core problem is how Master-Detail sharing actually flows. On your junction object: 

- Dealer is Master-Detail → the junction record's sharing/visibility is inherited FROM Dealer (parent controls child access) 

- Distributor is Lookup → no implicit sharing relationship in either direction 

This means: even if a user can see the Distributor record and the junction record, that does NOT grant them access to the Dealer record itself. Access flows downward from Master to Detail (Dealer → Junction), never upward or sideways. So your Distributor user seeing the junction row still can't see the related Dealer Account unless Dealer is shared with them directly and separately. 

Since Dealers are Accounts (many-to-many via the junction, not a single parent), a single Sharing Set access mapping won't work cleanly here — Sharing Sets are designed for one direct field match (e.g., a lookup field on the target object pointing back to the user's Account/Contact), and a Dealer can map to multiple Distributors, so there's no single static field to map against. 

Recommended approach: Apex Managed Sharing 

- Write a trigger (or a Flow calling an Apex action) on Distributor_Dealer_Mapping__c that fires on insert/update 

- When a mapping record is created linking a Dealer to a Distributor, programmatically create an AccountShare record granting Read (or Edit) access on the Dealer Account to the Distributor's related community users 

- This explicitly grants the access that Master-Detail/Lookup relationships and Sharing Sets can't provide automatically for this many-to-many pattern 

- If a mapping is deleted, make sure to also remove the corresponding AccountShare to keep access accurate 

This is the standard pattern anytime you have a many-to-many junction and need cross-visibility that doesn't follow simple parent-child sharing. 

2. Parent Account visibility for branch distributor users 

This is a known constraint of Sharing Sets specifically: Sharing Sets only grant access based on a single field match to the record directly associated with the logged-in user's own Account/Contact — there's no concept of "also see my parent account's data" built into Sharing Sets, since Sharing Sets are typically used for license types (e.g., Customer Community / high-volume login licenses) that don't get a Role Hierarchy. 

If you need hierarchy-aware visibility (branch distributor seeing parent distributor's Accounts, Orders, Invoices), you have two real options: 

Option A: Switch to a license type with Portal Roles (if feasible) 

Partner Community or Customer Community Plus licenses generate an automatic Role per external Account, and that role hierarchy respects your Account's Parent Account field. With standard sharing (Grant Access Using Hierarchies enabled, which is default), users higher in that hierarchy automatically see records shared to accounts below them. This is the "native" way to solve parent/child visibility, but it's a licensing change, not just a config change — worth checking if your current license supports this before going further. 

Option B: Apex Managed Sharing (if staying on your current license) 

Same pattern as above — when a Branch Distributor's Account is linked to a Parent Distributor Account, programmatically create Share records (AccountShare, OrderShare, custom object shares, etc.) granting the branch user's Account/community users access to the parent's records. This needs to run whenever the parent-child Account relationship is established or changed, and needs to be built out per object (Account, Order, Invoice, etc.) since each share type is separate. 

Given you're already on Sharing Sets (suggesting a license without native Role Hierarchy), Option B (Apex Managed Sharing) is likely your most practical path for both problems — it's more work upfront but gives you full control over exactly which records propagate to which users, including the many-to-many Dealer case and the hierarchical parent-account case.

@David Loyola -

• In Experience Builder open the Group Detail page → select Feed Publisher → set Type = Global (on a group page this targets the current group) to expose Poll/Question tabs — https://trailhead.salesforce.com/content/learn/modules/chatter_basics_for_users/chatter_basics_for_users_post
• In Setup → Chatter Settings enable Actions in the Publisher; then configure Publisher Layouts to include Poll and Question; ensure Chatter Questions is enabled — https://help.salesforce.com/s/articleView?id=platform.enabling_actions.htm&type=5 | https://help.salesforce.com/s/articleView?id=experience.collab_chatter_questions_overview.htm&type=5

Hi Rohit, 

The Knowledge User checkbox grants a user access to Salesforce Knowledge

features. Enabling it allows the user to work with knowledge articles, provided they also have the appropriate object permissions and permission sets. 

Typical use cases include: 

• Create, edit, publish, archive, and manage Knowledge articles.
• Access the Knowledge tab and article management features.
• Contribute to an organization's knowledge base for agents and customers.
• Use Knowledge articles while resolving Cases in Service Cloud.
• Participate in article approval and publishing workflows (if configured).
• View article versions, translations, and data categories based on permissions.

Simply enabling the Knowledge User checkbox does not

grant full access by itself. The user must also be assigned the necessary permissions (such as Create, Read, Edit, Publish, or Manage on the Knowledge object) through a Profile or Permission Set. 

In short, enable the Knowledge User checkbox only for users who need to create or manage Salesforce Knowledge articles, such as support agents, knowledge managers, or content authors.