#NPSP24 debatiendo

This typically occurs because the automated scoring package or managed flow tries to execute synchronously on newly inserted Opportunity or Contact records simultaneously with the GoFundMePro data sync. When high-volume or third-party payment integrations push records into your instance, the sudden influx of DML operations can cause lock contention or trigger depth limits, causing the scoring flow or trigger to fail before it can evaluate the $100 and 999-day threshold criteria. 

To resolve this, you should refactor or transition the scoring logic into an asynchronous process, such as a Queueable Apex job or a scheduled batch process, rather than letting it fire on immediate after-insert triggers from the payment portal. This decouples the GoFundMePro gift ingestion from the resource-intensive iWave scoring callouts, ensuring the donations sync cleanly first without being blocked by subsequent processing errors. 

Additionally, review the error logs in your Setup under Apex Exceptions or Process Automation Failures to identify the exact failing element. Adding explicit null checks and bulkified try-catch blocks within your wrapper handler will also prevent third-party integrations from stalling when missing secondary related fields during creation.

As far as I know, the managed communityFileList component in Grants Management does not expose a setting to exclude Notes, so the practical way to handle this is at the data/visibility level rather than in the component. 

Some background that helps here: Lightning (enhanced) Notes are stored as Salesforce Files. Each note is a ContentNote/ContentDocument with FileType = 'SNOTE', and it is linked to the Funding Request through a ContentDocumentLink record, exactly like an uploaded file. That is why a file list component picks them up. Whether an external (portal) user can see a linked file or note is controlled by ContentDocumentLink.Visibility: 'AllUsers' means external users with access to the record can see it, 'InternalUsers' means only internal users can. 

Options, from least to most effort: 

1. Check the component and the note visibility first. In Experience Builder, open the page with the file list and review the component properties (some versions let you filter by file type or related record). Then on a test note, check its ContentDocumentLink Visibility (for example via Developer Console: SELECT Id, ContentDocument.FileType, Visibility FROM ContentDocumentLink WHERE LinkedEntityId = '<FundingRequestId>'). If notes show as AllUsers, that is the root cause. 

2. Automatically make notes internal-only. A small before-insert Apex trigger on ContentDocumentLink can set Visibility = 'InternalUsers' when the linked record is a FundingRequest and the ContentDocument FileType is 'SNOTE'. Existing notes can be fixed with a one-off update of Visibility on their ContentDocumentLink records (Visibility is updatable). Test that the portal still shows the applicant's own uploaded files, which should remain AllUsers. 

3. Use a different place for internal comments. If you want a clean separation, capture internal comments on a record/object that portal users have no access to (for example a custom Internal Review Note object or a long text field hidden from the portal profile via field-level security), or use internal-only Chatter posts. 

4. If the managed component ignores visibility (for example because it runs in system context), replace it on the portal page with a small custom LWC or a Related List component that only shows files where FileType != 'SNOTE'. 

Useful references: 

File Visibility and Sharing in Experience Cloud Sites:

Work with Files in Your Experience Cloud Site:

ContentDocumentLink object reference (Visibility field):

Grants Management documentation:

Assumption: I could not find official documentation describing configurable properties of the managed communityFileList component, so I am assuming it respects ContentDocumentLink visibility and the portal user's access. Please validate the approach in a sandbox with a portal test user before rolling it out, and consider raising a case with Salesforce Support if the component shows internal-only notes regardless of visibility.

Hi @Maida Rider

Your second option scales better. Suggested setup: 

• Custom object “Compliance Requirement” as a child of Account (lookup or master-detail).
• Fields: Requirement Type (picklist: governance, policy, insurance, audit), Status, Issue Date, Expiration/Review Date, Reviewer, Notes.
• Files: attach documents to each Requirement record, not the Account. You get one history per requirement.
• Reminders: a scheduled flow on Expiration Date to create a Task or send an email to the owner. You can even define a standard review period based on the Requirement type field  (this will help standardize the process) 
• Account roll-up: a few fields on Account (for example “Compliance Status” or “# Expired”) using roll-up summary (master-detail) or a flow. Use these in reports and list views.
• Gate the funding: a validation rule or flow on the funding request/award that warns if the recipient has an expired requirement.

Use a small number of custom fields on Account only for the summary. Everything else stays on the child object