Give the public assistant a clear job
A website assistant can explain approved product information, guide visitors to resources and capture an enquiry through a configured action. It should not reveal private records because someone provides an email address, a case number or a familiar-sounding story.
Salesforce uses special restrictions for guest-user access. Any public information or action needs a deliberate design for that shared identity; a visitor is not automatically an authenticated Salesforce user. Salesforce’s guest-user security guidance is a useful starting point. [1]
- Identify the question
- Establish user identity
- Check permitted access
- Answer or hand off
A signed-in experience has a different starting point
An authenticated portal can associate the interaction with a known user. The implementation still has to establish which records, fields and actions are appropriate for that identity. Logging in does not mean the user may view every case at the company or every document attached to an account.
Keep sensitive account work in an experience with the appropriate identity and authorization checks. If those checks are unavailable, explain the limitation and provide a supported human route.
A worked example: “What is happening with my request?”
| Visitor context | Illustrative response design |
|---|---|
| Public website | Explain the general process and provide a sign-in or contact route. Do not reveal a record from a supplied identifier. |
| Authenticated customer portal | Retrieve the permitted request status and explain it within the configured scope. |
| Internal service colleague | Use the colleague’s applicable access and tools for the authorised service task. |
The public assistant can be helpful without disclosing status: it can explain where to find the reference number or how to reach the relevant team. Helpfulness does not require guessing who the visitor is.
Test the distinction rather than assuming it
- Try a known record identifier from a person who should not access it.
- Check what happens when the requested record belongs to another customer.
- Inspect whether a failed action is described accurately.
- Verify the handoff when authentication expires or information is unavailable.
Use approved synthetic records or a suitable test environment for those checks. A successful administrator demonstration is not a substitute for a guest or ordinary portal-user test.
Where REDA AI fits
REDA AI offers both website and portal experiences, configured around the intended work. Their access and action behaviour are channel-specific; neither should be described as universally inheriting the exact same permissions as every other surface.
The platform page describes the experiences, while Governance & Trust explains the distinctions. Begin with the question your customer needs answered, then select the channel that can answer it appropriately.
Sources
- Salesforce Developers — Give guest users access to read records. Accessed 22 September 2026.