Guest access for public forms

This page is for forms placed on Experience Cloud and open to the public. A form served from your Sliick Edge address does not need any of this: it reaches your org through the integration user you chose when you connected Sliick Edge.

Public forms on Experience Cloud are served to your Experience site’s guest user, and that visitor needs access set up before a form will load. Salesforce does not allow a managed package to ship a site guest profile, so this part is yours to configure. Work through it in order: each step fails with a different symptom, which is why a public form that “does not work” is rarely one problem.

1. Assign the Submitter permission set

Assign the packaged Sliick Forms Submitter permission set to the site’s guest user. A guest user can hold a permission set, and that assignment covers what the package can grant: read access to form definitions and elements, visibility on the fields the runtime reads, permission to send in a submission, and access to the one component a public form needs.

It is the recommended route for those grants, because it arrives with the package and cannot drift from what the product needs. It does not cover everything, though: step 2 has the one grant that is only ever set on the profile.

If you want to see exactly what is in it, open the permission set in Setup rather than working from a list here, because the permission set is the definitive record and it moves with the package.

The symptom of a missing assignment is Unable to load form where the component is placed on an Experience page.

Do not grant access to the package’s integration endpoints. A public form reaches Salesforce through the form component’s own session-protected connection, not through those endpoints. They are reserved for authenticated integrations, they are deliberately not on the Submitter permission set, and adding them would open submit, upload and resume to anyone on the internet with no caller you could name, limit or revoke.

2. Set the grants that live on the guest profile

Two of these are covered by the permission set already and are listed so you can recognise the symptom; the last one is not, and is the reason save-and-continue fails on a site that otherwise works perfectly.

The guest needs	Symptom when it is missing
Read on Form Definition and Form Element, and visibility on the fields the form runtime reads	The form does not load, or renders with pieces missing rather than erroring
Permission to send in a submission	Submitting fails with a server error
Permission to save a partial set of answers	Save and continue later fails for anonymous respondents, while the form still renders and still submits, so the symptom looks unrelated to setup. This one is not on the permission set: grant it on the guest profile

Grant the guest nothing at all on the response and partial-answer objects, not even read. See Why visitors never get access to response records, below.

This is also the classic problem after an upgrade. Field visibility lives on your own guest profile, so the package cannot manage it. A release that adds a field the public form reads needs that field made visible by hand. See Upgrading the package.

3. Never give the guest profile API Enabled

The site’s guest user must not have the API Enabled permission, by any route. This is not hardening advice: it is the control that keeps respondents’ answers off a subscribable feed, and nothing in the package can enforce it for you.

The reason is worth knowing, because “do not grant API Enabled” gets overridden by someone who has a reason. Permission to send in a submission unavoidably carries permission to read the same stream of submissions: Salesforce refuses to grant one without the other. Today an anonymous visitor cannot open such a stream, because doing so requires exactly the API Enabled permission the guest profile does not have. Switch it on and that stream becomes readable by anyone who can reach your site, carrying every respondent’s complete answers and every saved partial set of answers, including from people who never finished the form. Both can be replayed over a 72-hour window, so the exposure would be historical as well as live.

The realistic way this happens is not malice. It is an admin granting API Enabled to the guest profile while troubleshooting an unrelated integration, because nothing on that screen says what it costs.

Check it two ways, on install and after any change to the guest user, because the profile is only one of the routes:

1. The guest profile itself does not have API Enabled.
2. No permission set assigned to the guest user grants API Enabled, and no permission set group assigned to it carries a member set that does.

Neither check can be skipped on the strength of the other: an admin who granted an integration a permission set and added the guest user to it defeats this control without ever touching the profile. No permission set shipped with Sliick Forms grants API Enabled.

Do not try to fix this by removing the read half of the grant. Salesforce refuses that deploy. If your org genuinely cannot keep API Enabled off the guest profile, write to us rather than improvising: the public submission path depends on this.

4. Create the guest sharing rule

The permission set cannot do this part, and object access alone is not enough. With Secure Guest User Record Access enforced, which Salesforce mandates, an anonymous visitor sees no form definition rows until a sharing rule grants them.

1. Setup, Sharing Settings.
2. Find Form Definition and click New under Guest User Sharing Rules.
3. Configure:
   • Rule type: Guest user access, based on criteria
   • Criteria, with filter logic 1 OR 2:
     1. Is Active equals True
     2. Was Published equals True
   • Share with: the site’s guest user
   • Access level: Read Only
4. Save.

Both criteria matter, and the second one is easy to skip. A form that has been published and then had intake switched off must stay shared. Otherwise the visitor cannot reach the record at all, and respondents are told the form does not exist when they should be told it is closed.

A form that has never been published and is not active matches neither criterion and stays unshared, which is intentional: nobody should be able to confirm that such a form exists by guessing its URL.

Was Published is set the first time a form is published and is never cleared, so criterion 2 means “this form has been live at some point”. It exists because sharing criteria cannot test whether a lookup is filled in, and formula fields are not allowed in sharing criteria either.

Form Element needs no rule of its own: it is controlled by its parent and inherits this grant.

If a form reads as missing, fix the sharing rule rather than widening the profile. Sharing criteria are evaluated in system context and the package reads the relevant fields in system mode, so neither consults the visitor’s field permissions. Adding field access changes nothing except the surface area you have opened.

5. Make the site public and live

The site must be published, Live, and have Public Access switched on before it will serve the page to anyone who is not logged in. The exact settings are on Public forms on Experience Cloud.

6. Check your network settings

If your Experience site uses a custom domain, or you have tightened CSP or trusted-site settings, confirm the form page still loads for an anonymous visitor after publishing. If you embed the form on a site that is not Salesforce, that site’s address also needs to be an allowed origin in Setup, CORS.

Why visitors never get access to response records

You may notice that no packaged permission set grants access to the response object, and that you should not add it.

Every anonymous visitor to a site shares one Salesforce identity, and that identity would own every staged row. Read access on responses would therefore let any visitor read every other visitor’s answers.

Instead, an anonymous visitor only announces the submission, and the package creates the response record itself in an automated system process. The visitor never touches the object, and is never told the ID of the record its submission created. The same reasoning covers saved partial answers, which nobody is granted read access to, not even an administrator: a respondent’s resume link is the only way back to them.

Setup checklist

• Experience site exists, is published, is Live, and has Public Access on
• Sliick Forms Submitter assigned to the site’s guest user
• Guest profile granted permission to save a partial set of answers, if you use save-and-continue
• The guest has no access of any kind to the response and partial-answer objects
• The guest user has no API Enabled permission by any route: not on its profile, not through an assigned permission set, and not through a permission set group
• The guest has no access to the package’s integration endpoints
• Guest sharing rule on Form Definition, Read Only, filter logic 1 OR 2 on Is Active and Was Published
• Smoke test: open the form page in a private browser window, with no Salesforce session, and submit it
• The submission appears in Sliick Responses, which can take a few seconds