Thursday, May 28, 2026

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.









Tuesday, May 26, 2026

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

Friday, May 22, 2026

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.

Thursday, May 14, 2026

Ignore Cache; When to use it in OmniStudio; Different cache options & their locations

 



Development / Testing

  • ✅ Enable Ignore Cache
  • ✅ Disable Card Cache for your user/profile. Where to check Disable Card Cache- 


Production
  • ❌ Leave Ignore Cache off
  • ✅ Cache only non‑sensitive, stable data
  • ✅ Use Session Cache for user‑specific data





API End Points to Get & POST; HTTP Integration

 POST : 

https://gorest.co.in/rest-console

External sites need to be added below - 



https://api.chucknorris.io/


GET:



Use Expression For Value; SetError Action Omniscript