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.

Check What Input Is Sent to a Data Mapper from an OmniScript

While testing an OmniScript, I ran into a situation where I needed to confirm what input data was actually being sent to a Data Mapper. The UI shows the mapping, but that doesn’t always guarantee the exact value being passed at runtime.

Here’s a simple and reliable way to verify it using Action Debugger.

---

Scenario

• An OmniScript calls a Data Mapper (Extract Action)
• An input parameter (for example, Agent_Email) is passed from the OmniScript JSON
• That parameter is then used in an Extract Object filter (for example, filtering Contacts by Email)

I wanted to make sure:

• The parameter exists
• The value is populated correctly
• The Data Mapper receives the expected value

---

Step 1: Configure the Data Mapper Input

In the Data Mapper Extract Action inside the OmniScript:

• Set the Data Mapper Name
• Under Input Parameters, map the input like this:

Contact Information:Agent_Email 

This means:

• Agent_Email is expected to come from the OmniScript JSON
• The Data Mapper will receive it under DRParams

---

Step 2: Verify the OmniScript Input JSON

Open Manage Input/Output Type → Edit Input JSON.

Make sure the value is present:

{

  "Agent_Email": "user@example.com"

}

✅ This is important
If the value is missing or null here, the Data Mapper will not receive it—even if the mapping looks correct.

---

Step 3: Use Action Debugger (Most Important Step)

Now run the OmniScript in Preview mode and open Debug → Action Debugger.

1. Find the Data Mapper Extract Action
2. Expand Request Data
3. Look for the DRParams section

You should see something like:

"DRParams": {

  "Agent_Email": "user@example.com"

}

``

✅ This confirms:

• The OmniScript passed the value correctly
• The Data Mapper received the expected input
• Any issues after this point are inside the Data Mapper logic itself

---

Step 4: Confirm the Data Mapper Response

In the same Action Debugger entry, check the Response section.

If the input is correct, the response should contain the expected records (for example, matching Contact emails).

---

Key Takeaways

• Action Debugger is the source of truth for what is actually sent to a Data Mapper
• Always check Request Data → DRParams
• Do not rely only on UI mappings—runtime data can differ
• If the value is missing in DRParams, first check:
  • OmniScript Input JSON
  • Data Mapper input parameter mapping

---

Why This Helped Me

This approach saved time by:

• Quickly isolating whether the issue was in the OmniScript or the Data Mapper
• Avoiding unnecessary changes to filters and queries
• Making debugging more predictable and repeatable