Troubleshooting and Debugging15% of the exam

Troubleshooting Omnistudio permissions and data access

How to diagnose Omnistudio access failures from the symptom: Omniscript errors that really mean missing object, field or record access, unsecured cached Integration Procedures, Flexcard data source types hidden by Omni Interaction Access Configuration, guest users who get no records, and Data Mapper field-level security.

Official exam objective
Resolve incorrect permissions and access issues.

~8 min read · 5 practice questions ·

What the exam expects

  • Read an Omniscript access error (including messages that ask for reactivation) as a permissions problem and check object, field and record access.
  • Secure cached Data Mappers and Integration Procedures that rely on Sharing Settings with CheckCachedMetadataRecordSecurity.
  • Find why a Flexcard data source type is missing for one profile or user in Omni Interaction Access Configuration.
  • Fix guest users who see no records with criteria-based sharing rules, and enforce field-level security on one Data Mapper or on all of them.

Key terms:

  • Required Permission: Data Mapper and Integration Procedure property that decides who can run it.
  • CheckCachedMetadataRecordSecurity: setting that adds a record-level check to cached metadata.
  • Omni Interaction Access Configuration: Setup records (Org_Wide, Profile or User) that turn Flexcard data source types on or off.
  • Check Field Level Security: Data Mapper Options tab checkbox that enforces field-level security for that Data Mapper.
  • EnforceDMFLSAndDataEncryption: Omni Interaction Configuration entry that enforces field-level security for all Data Mappers.

Key facts

Reactivation message cause
Detail
Insufficient object, field or record access, or missing Omnistudio object permissions
forceGenerated module not found
Detail
Grant access to OmniProcess, OmniProcessElement, OmniProcessCompilation
Blank Required Permission
Detail
Any user can run it unless DefaultRequiredPermission is set
CheckCachedMetadataRecordSecurity default
Detail
False; true adds a record-level check for cached metadata
Standard user permission set
Detail
Clone Omnistudio User, check both System Permissions checkboxes, then set object access; the create-instances permission can stay off for read-only users
Parent Integration Procedure
Detail
Can invoke children the user can't access directly
One Data Mapper FLS
Detail
Options tab, Check Field Level Security
All Data Mappers FLS
Detail
EnforceDMFLSAndDataEncryption set to true
Guest record access
Detail
None by default; criteria-based sharing rules grant read-only
Flexcard data source default
Detail
All types enabled org-wide
Per-profile or per-user types
Detail
Access configuration record with Location Profile or User
Sources for this section (6)
  • Why should you check user access when an Omniscript asks to be deactivated and reactivated but admins run it fine?
  • When must CheckCachedMetadataRecordSecurity be true?
  • Why does a Data Mapper that reads records for you in Preview return none to a guest?
  • When would you create an Omni Interaction Access Configuration record with Location Profile or User instead of editing Org_Wide?

The questions are free to read. Answers with their sources and self-grading are included with the pack.

Keep reading with the Omnistudio Developer pack

  • Core concepts
  • Exam traps
  • Worked scenario

The pack includes:

  • All 46 lessons of the Omnistudio Developer guide, with reading progress
  • Interactive decision walks and step-by-step sequence steppers
  • Inline practice questions and one-click topic practice (5 questions for this lesson)
  • An official source cited for every claim
  • An AI tutor that answers from the guide
  • Unlimited timed practice exams

Practice for the Omnistudio Developer exam