#Salesforce Admin토론 중인 항목 357개

Hi @John Fine

Both are reasonable. Which tool you should use will depend on what you are rolling up: 

• Customizable Rollups understand NPSP concepts (soft credits, household and contact rollups, time-bound rollups, GAU allocations). They are configured in the NPSP settings UI, run as batch jobs, and stay inside the managed package.
• DLRS works on any object (including custom ones and outside NPSP), can update quickly by trigger, and is actively maintained by its community. It requires deploying Apex, and someone has to own it when you leave.

Use Customizable Rollups for standard NPSP giving metrics, and DLRS only for rollups NPSP cannot do. Do not run both on the same target field. Whichever you pick, document it, and check batch times on your data volume. 

 Hi @Michelle Chang, 

Have you checked out the AppExchange to see if there are any apps that you can use instead of doing any custom dev?

• I could find few options for both Stripe and Aquare

https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FnCw4UAF

I hope this helps.

Thanks for testing those, Souvik - since browser, My Domain, and admin are all ruled out, that error is almost certainly coming from one specific org-wide setting: 'Require Proof Key for Code Exchange (PKCE) Extension for Supported Authorization Flows' in Setup > OAuth and OpenID Connect Settings. 

Here's the trap: you mentioned enabling PKCE there. When that org-wide toggle is on, the org forces a code_challenge on every supported authorization flow - but the internal namespace-linking flow doesn't send one, so it fails with exactly 'missing required code_challenge'. So that setting being enabled is what's breaking the link, not something you're missing. 

The fix: turn that setting off (Setup > OAuth and OpenID Connect Settings) in the org that owns the namespace - and in the Dev Hub too if it's enabled there - then retry the namespace link. Once it's linked, you can switch it back on if you want PKCE enforced for your own apps. Note this org-wide toggle is separate from the greyed-out PKCE box on the Salesforce-managed connected app you can't edit - this one you do control. 

If it's already off and still fails, then it's on Salesforce's side (the managed linking app), and the right path is a Partner Support case referencing the error - it's a managed flow you can't patch yourself. But I'd bet on the org-wide setting; toggle it off and the link should go through. 

Hope that finally clears it! 

And if this resolves it, please mark it as the Best Answer so it helps the next person who hits this - thanks! 🙂

@Vincent Laplanche This is a common challenge for businesses working with large files, especially when those files need to be shared through a public-facing Experience Cloud site. 

One approach is to offload the files to a system built specifically for document storage and security. Instead of storing and delivering the files through Salesforce, you can keep them in SharePoint while Salesforce continues to manage the customer and business data. 

Customers can log in to Experience Cloud and access the appropriate SharePoint files through secure links and controlled permissions. These links can be locked down, so only the required permissions are given to those who need it, instead of the public links you are experiencing currently. 

sFiles connects Salesforce and SharePoint for exactly this type of use case. It supports file uploads, links, and access directly within Experience Cloud, so the files remain available to both your internal Salesforce users and external customers without being stored in Salesforce. 

An additional benefit is reduced Salesforce file-storage usage, which can become very expensive when large files are uploaded regularly. 

I just found this post because I had the same problem. As we now found the solution I would also like to share here, in case you still have the problem or someone else finds it. 

For us it was under Setup -> Session Settings -> Browser Feature Permissions -> Allow Microphone Always (or trusted side only, then you need to add your instance url under trusted sites) 

And "Lightning Web Security" needs to be activated. 

Hi Lena, since both orgs are on the same laptop/browser and your Salesforce config in Org B genuinely looks correct, this is very likely a browser/Windows-side caching issue tied to the different origin (domain), not a Salesforce policy difference. A few things worth checking: 

1. Check Windows' own Passkey manager for a stale entry. Go to Windows Settings → Accounts → Passkeys (or Sign-in options → Passkeys). Look for any existing entry tied to Org B's domain — even a partial/failed registration attempt from earlier can cause Windows to skip the "create new" platform flow and jump straight to the cross-device/roaming flow instead. Delete any entry there for Org B's domain, then retry from Salesforce. 

2. Clear the browser's per-site permissions for Org B's domain. Chrome/Edge cache a "last used transport" preference per relying-party origin. In Chrome: Settings → Privacy and security → Site settings → search for Org B's domain → Clear data/reset permissions. This forces the browser to re-evaluate available authenticators instead of defaulting to whatever you (or a prior session) picked before. 

3. Confirm Org B's My Domain is fully deployed, not just the default login URL. WebAuthn ties credentials to the Relying Party ID (essentially your domain). If Org B is still on a default/undeployed domain or recently changed its My Domain, the RP ID Salesforce sends can differ from what you'd expect, which changes how the browser matches existing/available authenticators. 

4. Try a fully fresh browser profile/incognito window against Org B only, to rule out any extension (you mentioned Microsoft Authenticator extension is on in both — try disabling it just for this test) or cached state interfering specifically with that origin. 

5. As a last resort, use "Disconnect a passkey that isn't working" from your Salesforce personal settings (Advanced User Details → Built-In Authenticators → Del on any existing/broken entry for Org B), then try Add again from a clean state. 

If none of that breaks the loop, this is worth escalating to Salesforce Support directly with both orgs' IDs — a same-device, same-browser, config-identical discrepancy between two orgs isn't something Setup-level settings can explain, and Support can check server-side registration options (like exclude-credential lists) that aren't visible from the UI. 

Reference: