#Experience Site13 discussing

@Rahul Kumar

try checking these threads -  

Hi Kushagra, 

Yes, creating an IAM user is the correct path, and it's confirmed by AWS's own official documentation, not just common practice. AWS explicitly recommends creating an IAM user with least-privilege permissions first, then generating access keys under that IAM user, never using your AWS root account credentials for this. 

Steps to get your Access Key and Secret Key (official AWS process): 

1. Log into the AWS Console with your root/admin account (only for this setup step, not for ongoing use). 

2. Go to IAM > Users > click "Create user". 

3. Give it a descriptive name, e.g. salesforce-s3-integration. 

4. Do NOT enable AWS Management Console access, this user only needs programmatic access, not console login. 

5. Attach a permission policy scoped only to what's needed, ideally a custom policy limited to s3:GetObject on your specific bucket/prefix, not full S3 access. This follows AWS's least-privilege guidance. 

6. After the user is created, go to that user > Security credentials tab > Access keys section > "Create access key". 

7. Select the use case (choose "Application running outside AWS" or similar, matching your Apex callout scenario). 

8. AWS shows you the Access Key ID and Secret Access Key ONCE. Download the CSV or copy both immediately, the Secret Access Key cannot be retrieved again after this screen, you'd have to delete and recreate the key if lost. 

Official reference:

Important note on "is this the only way": Technically no, AWS's own best-practice guidance actually recommends AGAINST long-term access keys where avoidable, and prefers IAM Roles with temporary/short-term credentials (via AWS STS) since those auto-expire and reduce risk if leaked. 

Official reference:

However, for a Salesforce Apex integration specifically, since Apex runs outside AWS and can't assume an IAM role directly the way an EC2/Lambda service can, using a scoped-down IAM user with long-term access keys (stored securely in Named Credential/Protected Custom Metadata, as I mentioned earlier) is the practical and accepted approach here. Just make sure to: 

- Scope the policy to only that one bucket/prefix 

- Rotate the access key periodically 

- Never commit it to code, always pull from Named Credential/Custom Metadata at runtime 

So to directly answer: yes, IAM user + access key is the right and standard way for your use case.

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.