Skip to content

Getting Started

Set up your Experience Cloud site#

Public donation pages, the donor portal, and event tickets all run on an Experience Cloud (Enhanced LWR) site. Pledgivo ships every component that goes *on* that site — it doesn't create the site itself. That's a one-time manual setup you do in Salesforce Setup, not something the package installs for you.

Internal-only orgs can skip this

If you're only recording gifts staff take over the phone and never publishing a public donation page, you don't need Experience Cloud at all — skip ahead to Setup assistant.

Before you start#

Confirm your org edition supports Experience Cloud — Enterprise, Unlimited, Performance, or Developer. Professional edition can't publish public pages; see Installation.

1. Enable Digital Experiences#

Setup → Digital Experiences → Settings → Enable Digital Experiences.

Until you tick this, Digital Experiences does not appear in Setup at all — there is no All Sites list and nothing to create. Salesforce asks you to choose an Enhanced Domain subdomain as part of switching it on; that name becomes part of every public donation URL, is org-wide, and cannot be undone, so pick one you are happy to publish.

The Settings console's Site & Domain panel is an eight-step checklist that starts with this same step, machine-checks it against your org, and links you straight to the Setup page.

2. Create the site#

Setup → Digital Experiences → All Sites → New.

  1. Choose the Build Your Own (LWR) template.
  2. Name the site (e.g. "Giving" or your org's name). Salesforce derives the URL prefix from this name — if it appends a suffix like vforcesite because your preferred prefix was already reserved elsewhere, you can change it afterward under Experience Builder → Settings → URL & Access.
  3. Click Create. Site creation runs as a background job and can take several minutes.

All Sites renders an empty pane

On some orgs the All Sites screen loads its shell — breadcrumb, heading — and then shows nothing at all: no site table, no New button. A hard reload does not fix it. It is the same blank-shell behaviour the Lightning Permission Sets page sometimes shows, and it has nothing to do with this package; it simply blocks the documented path.

Create the site from the CLI instead — it produces exactly the same site:

sf community create --name "Giving" --template-name "Build Your Own (LWR)" \
  --url-path-prefix giving --target-org <your-org-alias>

Creation is asynchronous either way. Confirm it landed with:

sf data query --query "SELECT Name, Status, UrlPathPrefix FROM Network" --target-org <your-org-alias>

Read the prefix back rather than assuming it. Salesforce may return something other than what you asked for — giving came back as givingvforcesite on a first-ever site in a completely clean org, not only when the prefix was already taken. Never hardcode the prefix anywhere; take it from that query.

3. Build the Donate page#

Campaigns, fundraiser pages, team pages, and event registration all share one page and one component — Public Fundraising Experience. It reads the campaign's record type, subtype, and URL slug to decide what to render, so you only build this once regardless of how many campaign types you run.

  1. Open the site in Experience Builder.
  2. Pages → New Page → Standard → Flexible Layout.
  3. Name it (e.g. "Donate") and, in Page Properties, set its URL — e.g. donate.
  4. Drag the Public Fundraising Experience component into the content region and Save.

A campaign's public link then looks like https://<your-site-domain>/donate?slug=<the campaign's public URL>.

Component missing from the palette?

Publish the site and hard-refresh Experience Builder — a newly-installed component sometimes doesn't show up until the org's cache picks up the change.

Built the Donate page at a URL other than donate?

Set Donation page path to match, in the Settings console: General → Organization & Donations → Gift rules. The Campaign Gallery's donate links, the embed widget's checkout handoff, and the Fundraisers console's public-links panel all build their URLs from this setting — it defaults to /donate, so leaving it blank while your page lives somewhere else silently breaks every one of those links with a 404. Leave it blank if you used the default donate path above.

4. Build the other pages you need#

Each of these pages is independently optional, but other pages link to them by URL — using a different path than the one listed breaks that link with a 404. Build only the ones your rollout actually uses:

Page URL Component Needed for
Home / Campaign Gallery A public campaign directory — many sites already have a Home page, in which case just add the component to it
Thank you thank-you Thank You Event checkout — the buyer is sent here immediately after a successful charge
Receipt receipt Donation Receipt Anyone you email a receipt link to — build this if you send receipts at all
Donor portal donor Donor Dashboard The magic-link donor self-service portal — see Publish a donor portal page
Tickets tickets Event Tickets Event ticketing. The Donor Dashboard links here on every event order — skipping this page breaks that link even if you don't otherwise use the Tickets page directly

thank-you, receipt and tickets are fixed paths — build them exactly as written. donate and donor are configurable in the Settings console under General → Organization & Donations and General → Email & Receipts. The Site & Domain panel's step 7 shows the paths your org is actually configured with, plus a live link to each page so you can confirm it loads.

Build each the same way as the Donate page: New Page → Standard → Flexible Layout, set the URL in Page Properties, drag in the named component, Save.

Thank you is not optional if you sell tickets

Event checkout navigates to thank-you right after the charge succeeds. An org that skipped this page takes the buyer's money and lands them on a 404 — the failure happens after payment, so nothing earlier in your testing catches it.

5. Activate guest access#

Setup → Digital Experiences → All Sites, then click Workspaces next to your site → Builder → Settings → General. Enable Public Access — without it, every visitor gets a login page instead of your donation form, no matter what permission sets are assigned below. Salesforce exposes no API to read this toggle back, so you're confirming it yourself; the Site & Domain panel marks this step Can't verify for the same reason, not because anything is wrong.

Then assign Fundraising_GuestDonor to that site's guest user. Finding the guest user is the awkward part, so follow this route exactly — you will come back to it twice more below:

  1. From that same Builder → Settings → General screen, click the link under Guest User Profile.
  2. On the profile, click View Users. Exactly one user is listed — "<your site> Site Guest User".
  3. Open that user → Permission Set Assignments → Edit Assignments → move Fundraising_GuestDonor across → Save. Leave the License filter on --None--; the guest user holds no license, so filtering by one hides the set you are looking for.

Two routes that look right and are not: Administration → Members assigns profiles and permission sets that may be members of the site, not permission sets to the guest user; and the guest user does not appear under Setup → Users at all, nor in Manage Assignments on the permission set itself. Without this assignment, guest visitors can view campaign pages but the donation form cannot submit — see Installation.

Next, grant that Guest User Read on the standard Campaign object. Fundraisers are Campaign records, and Salesforce does not let a managed package ship permissions on standard objects — they are removed when the package version is built — so Fundraising_GuestDonor carries every custom object and field grant your public pages need and can never carry this one. Without it a visitor gets an error on every campaign, donation and ticket page. Do it in Setup → Profiles → your site's guest user profile → Object Settings → Campaigns → Edit: tick Read and nothing else. A guest user must never hold Create, Edit or Delete on Campaign. Granting it through a permission set of your own and assigning that to the guest user works equally well. This one is machine-checked: the Site & Domain panel's step 5 reads the grant back and reports Done or Pending.

Finally, grant the public Stripe credential to that same Guest User — the same Builder → Settings → General → Guest User Profile → View Users route as above. Salesforce does not let a managed permission set grant access to an external credential principal, so this package can never ship that grant — you create your own permission set holding that credential's OrgPrincipal and assign it to the guest user as well as to your fundraising staff. Keep the admin credential's grant on a separate permission set that the guest user is never assigned: it carries the full secret key, so a guest user holding it can issue refunds. Unlike the Public Access toggle above, this one is machine-checked: the Site & Domain panel's step 6 reads the grant back via SetupEntityAccess and reports Done once a permission set granting the public credential's principal is assigned to the site's guest user, or Pending with the specific reason (no grant found at all vs. granted but not assigned to this guest user) otherwise. That step grades the public credential only — on the Payments panel, Let your public site use the credential names the exact permission sets your guest user holds so you can confirm none of them is the admin one, and Prove the public key is restricted catches the same exposure from the other side by proving the key a guest can reach cannot issue a refund. Full walkthrough: Grant the Stripe credential.

6. Publish, then activate#

These are two separate actions on two separate screens, and you need both. Publishing without activating is the single most common reason a donation link 404s for donors while working perfectly for you.

Publish. Click Publish in Experience Builder (top-right). This is a separate step from saving your pages — nothing you build in Builder is visible to guest users until you publish.

Activate. Setup → Digital Experiences → All Sites → Workspaces beside your site → Administration → Settings → Activate. Only this moves the site's status from Preview (UnderConstruction) to Live.

Publishing does not activate

Experience Builder will report Published with a live URL on a site the public still cannot reach. Builder has no Activate control at all — the button is in Workspaces, and the Settings console's Site & Domain and Get Started panels are both graded on the activation status, not on whether you have published. A successful publish leaves both rows amber until you activate.

Publish again after every future change

A metadata deploy alone does not update the live site — a package upgrade or a Settings change to page composition still needs an explicit Publish to go live. Hard-reload the page after publishing before you verify anything — a cached bundle can make a successful publish look like it didn't take effect. Activation, once done, stays done.

Next#