Quick Guide: Components Needed for Migrating a Salesforce Experience Cloud Site

 

Display PDF Documents in a Visualforce Page from OmniScript; Secured Guest User

 

Apex: 

Overall flow:

ContentVersion File

│

▼

AutoGenDocPreviewController

│

▼

Base64 PDF String

│

▼

Visualforce Page

│

▼

JavaScript atob()

│

▼

Binary PDF

│

▼

Blob

│

▼

Temporary URL

│

▼

iframe

│

▼

PDF displayed in browser

Why This Approach Is Useful for Guest Users

Instead of exposing the file directly through:

/servlet/servlet.FileDownload?file=...

the Apex controller retrieves the file and sends it as Base64. The browser reconstructs the PDF locally.

This is often used when:

• Guest users cannot access ContentVersion directly.
• Secure Guest User Access is enabled.
• Files are owned by an integration user.
• You need custom security checks before showing the document.

Enabling users without Orchestrator access to debug on the host machine; UiPath

 

​When interactive authentication is enforced, in UiPath Assistant, a user can only see the processes to which they have access and only after signing in to their account. A user license is also required. Therefore, unattended processes which do not run under a user account are not available in UiPath Assistant for troubleshooting, making it impossible for a user to debug an unattended process by logging into that host machine.

To overcome this, an administrator can temporarily enable a troubleshooting session on their machine. Doing this lets the user see and run the unattended process locally, without requiring a user license. The troubleshooting session is temporary and the above only applies while troubleshooting is active.

You can also use Studio for its remote debugging capabilities. It allows running and debugging attended and unattended processes on remote machines, including on Linux robots that can run cross-platform projects.

Step 1. Enable a troubleshooting session​

1. Go to Tenant > Monitoring.
2. Select Unattended sessions from the Section dropdown menu.
3. Identify the machine where the error occurred, click More Actions at the end of the machine row and select Configure troubleshooting session.

The option is only available if interactive authentication is enforced.

You can find out on which machine a process ran by selecting the Processes section.

The Configure troubleshooting session dialog opens:

Figure 5. Configuring troubleshooting session

4. Under Troubleshooting session, click the toggle to switch it to Enabled.
5. In the Session timeout (minutes) box, edit the value to change the number of minutes the troubleshooting session should be active.

https://docs.uipath.com/orchestrator/automation-suite/2023.10/user-guide/configuring-automation-capabilities

Making OmniScripts Publicly Accessible: A Clear Guide

 The blog covers how to expose OmniScripts to external users via Experience Cloud (Salesforce portals/communities), but it jumps around between concepts. Here's what you actually need to do, in simple terms as mentioned in omnistudiofacts

The Three-Layer Permission Model

To make an OmniScript accessible to external users (like customers or partners using your Salesforce portal), you need to configure three permission layers.

1. Org-Wide Defaults (OWD) - Set Baseline Visibility

This controls what external users can see by default across your entire org. You need to:

• Go to Setup → Sharing Settings

• Click Edit on Organization-Wide Defaults

• Search for all Omni-related objects (OmniProcess, OmniScript, etc.) and Vlocity objects

• Set Default External Access to Public Read Only (or Public Read/Write if they need to create data)

Why this matters: Without this, external users are completely blocked from seeing OmniStudio elements, even if you grant other permissions.

2. Sharing Rules - Grant Access to Specific Records

OWD sets the baseline, but sharing rules open up access to actual OmniScript records. You need to create sharing rules for these objects:

• Omni Process

• Saved OmniScript

• Vlocity OmniScript

• Omni Data Transformation

• Omni UI Card

• Plus several DataRaptor-related objects (about 12 total)

How to set them up:

• Go to Setup → Sharing Settings

• For each object listed above, click New under its Sharing Rules section

• Choose Guest user access, based on criteria

• Set criteria: OwnerId or CreatedById Does Not Equal Null (this includes all records)

• Share with: Your Experience Cloud community name

• Access level: Read Only

Why this matters: Even if OWD allows visibility, sharing rules determine which specific OmniScript records external users can actually access.

3. Profile Permissions - Enable OmniStudio Features

The external user's profile (like "Customer Community User") needs these permissions enabled:

Critical permission:

• Under General User Permissions, enable: "Enables consumers and partners to execute OmniScripts, DRs, and Cards through a Community or off the platform"

Additional permissions to grant:

• Apex Class Access: Add all OmniStudio-related Apex classes

• Custom Metadata Type Access: Enable OmniStudio custom metadata types

• Object Permissions: Grant Read (and Edit if needed) on Omni/Vlocity standard and custom objects

Why this matters: This is the final switch that actually allows external users to execute OmniScripts - without it, nothing works even if data visibility is correct.

Below are not required but is recommended.

How to Restrict File Upload to a Single File in OmniScript (Salesforce OmniStudio)

When working with OmniScript in Salesforce OmniStudio, file uploads are a common requirement—whether it’s for document submission, verification, or case processing. However, one limitation many developers encounter is restricting users to upload only one file.

Add Formula Field to count the number of Files Uploaded.

Set Messaging element to check the value and restrict the next step. 

https://youtu.be/U5EuCACXpjA?si=_OiiAuqThL9N_QA7

DebugJSON Custom LWC to check Omniscript DebugJSON/DataJSON on Step function; Omnistudio

 

Clear cache and reactivate Omniscript on the browser

 

When updating an Integration Procedure or OmniScript (layout or values), make sure to clear cache and reactivate before testing. Otherwise, changes may not reflect correctly. Cache issues can cause outdated values to appear on the test screens.

When working with Integration Procedures (IP) and OmniScripts, it’s common to make updates to layouts, data mappings, or values and expect immediate results during testing. However, one often overlooked factor can lead to confusion—caching.

🚨 The Issue

After making changes, you may still see old values or layouts during testing. This can make it seem like your updates didn’t apply, even though everything is configured correctly.

✅ The Fix

Always follow these steps after making updates:

1. Clear cache
2. Reactivate the Integration Procedure or OmniScript

💡 Why This Happens

OmniStudio components leverage caching for performance optimization. If not cleared, cached data can continue to serve outdated responses, especially in multi-step flows where previous screens rely on stored values.

🧪 Real-World Insight

I encountered this while testing updates—everything looked correct in configuration, but the UI still showed old data. Clearing the cache and reactivating immediately resolved the issue.