#Experience Site11 diskutieren mit

Hey Vishal, 

This matches a documented Salesforce Known Issue: Internal Server Error in Experience Builder when creating/accessing page variations. It's a recognized platform bug tied to how the builder handles new page creation for certain page types, not something wrong with your API name or setup. 

Workaround from Salesforce's own known issue documentation: 

1. Open Experience Builder, open the Pages menu 

2. Locate the affected page, click the three dots next to it, go to Page Properties 

3. From there, try creating the page fresh as a page variation with a basic/blank layout rather than through the standard "New Page" flow 

If this workaround doesn't resolve it for you, per the same known issue, the recommended next step is opening a case with Salesforce Support directly, referencing this as matching the known "Internal Server Error in Experience Builder when accessing page variations" issue and providing your specific Error ID (628191604-286554) so they can trace it against the root cause already on file. 

Reference:

Jordan, if there’s no component-visibility filter, I’d check the Guest User Profile permissions and how the button itself is configured.

Since the flow already runs in System Context Without Sharing, the execution mode probably isn’t why the button is missing. I’d compare the guest user’s access to the object, Apex classes (if used), and the Experience Cloud page.

Also check whether these are Dynamic Actions rather than an Experience Builder Flow component, since their visibility can be controlled separately.

As a quick test, try adding the same flow through the standard Flow component and view the page while logged out. If that works, the issue is likely with the button/action configuration rather than the flow itself.

Lucas is spot on about the layer to target - here's the concrete how. The key is that the Edit button is driven by the page layout's actions, which is completely separate from the object/field edit permission on the profile or permission set. So you can pull the button without touching the access your offline package needs. 

The package syncs through the API, not the UI, so removing the on-screen Edit action doesn't affect it at all - the permission stays, only the button goes. 

Steps: 

1) Clone the page layout your partner users get for the custom object (so internal users aren't affected). 

2) On the cloned layout, expand the 'Salesforce Mobile and Lightning Experience Actions' section, click to override the predefined actions, and remove the Edit action (plus any Edit-style quick actions). If that section still shows the default set, you have to click 'override' first before it lets you customize it. 

3) Assign that layout to the partner profile (Page Layout Assignment on the object, per profile / record type). 

Two things to check depending on how the site is built: 

- If your Experience Builder record page uses the standard Record Detail / Record Banner component, it honors the layout actions, so step 2 handles the Edit button. 

- If it uses a custom component or a custom Action list on that component, the actions are defined there instead - edit the component's action list in Experience Builder rather than on the layout. 

Also worth closing off: inline editing (the pencil on fields) and the Edit row-action in any list views or related lists on the site, since those are other ways to edit. Inline edit can be turned off so they can't bypass the missing button. 

Net effect: partner users keep full edit access for the offline sync (via API), but the community UI is effectively read-only - exactly the split you're after.

Hello @Tushar Jadav

Thanks for your suggestion. 

The user's license is

I tried your solution, but it doesn't work for my issue, I still get the same error. 

What could be the issue?

@Roopa Sharma in your home page screenshot for the compact header settings, there is no image set there, whereas in your My Policy page there is.

Here is what I think is happening:

• On your home page, you have the Hero component showing.
• The background image is set for the Hero component, not in the header.
• In your Theme Layout Settings, you have the Hero set to start under the header (which means the header will overlap the hero).
• In your header you have the background color as clear.
• So, with all this, your header is overlapping the hero, and it has a clear background, so the hero's background image is showing up through the header. Since the hero is fairly tall, that's why it looks so big.

On your other pages, you don't have a hero and instead your header component is using a background image rather than being transparent.

The User needs the System Permission 'Field Service Standard'. Assigning the permission set license with the same name is not enough.