How do you fix this cross scope issue for failing widgets?

jpcb0108 · 6 hours ago

Hi,

Currently working on some Lifecycle Event Activities. Then I noticed that when I open an activity that requires the user to select a catalog item in the ESC portal, a lot of errors pop out due to cross scope issues. I am quite unsure what specific information to put on the Restricted Caller Access Privilege table as the Source and Target seem to be the same from Journey designer scope but that shouldn't be the case that source and target are the same right? Would like to get some guidance on how I should fill up the Restricted Caller Access Privilege table to allow this widget to function again. Attached is the list of errors I get when visiting the Lifecycle Activity.

Thank you.

G Ponsekar · 6 hours ago

Hi @jpcb0108 ,

To properly fill out the Restricted Caller Access Privileges table for your Lifecycle Event activity, you need to understand that even within a parent application (like HRSD), different child application scopes must explicitly grant permission to one another. The key is to correctly identify the calling component (Source) and the component being called (Target) from the error messages.

The reason you see "Journey Designer" as both the source and target is a bit misleading. The error is likely occurring within the context of the Journey Designer, which is trying to load a component (the Catalog Item selection widget) that belongs to a different scope

How to fill out the Restricted Caller Access record

The most reliable way to create a valid RCA record is to let the system generate it automatically, then approve it.

Reproduce the error: As an administrator, navigate to the Lifecycle Event activity in the ESC portal and open the task that causes the error. This action will trigger a new "Requested" RCA record.
Navigate to the RCA list: In the Application Navigator, go to System Applications > Application Restricted Caller Access.
Find the new RCA record: Filter the list to find records where the Status is Requested or Invalidated. You can also sort by the Updated column in descending order to see the most recent ones.
Analyze the RCA record:
- Source Scope: This will be the scope of the component that is trying to access another resource. In your case, this is likely one of the HRSD scopes, the Employee Center Core scope, or even a specific widget's scope.
- Target Scope: This will be the scope of the catalog item or the table it's trying to access. This could be HR Core or another scope.
- Target: The specific resource being accessed, such as a table, script include, or script action. The error message you see on the screen will almost always tell you the exact target, like Execute operation on script include '....
- Operation: The type of access being requested, such as Execute API for script includes or Read for table records.
Approve the RCA record:
- Change scopes: Before changing the status, switch your application scope to the Target Scope of the RCA record. You cannot approve access to a scope you are not in.
- Update the status: Open the RCA record and change the Status from Requested to Allowed.
- Save the record: Save the form to apply the change.

The Source/Target scope paradox

It is important to note that it's possible and common to see RCA records where the source and target scope are the same. This can happen when a Service Portal widget (which has its own scope) calls a script include or table that is in the same parent application scope. The platform is designed to enforce access control even within a single application family.

If I could help you with your Query then, please hit the Thumb Icon and mark as Correct !!

Thanks, GP

jpcb0108 · 3 hours ago

Thanks. I tried searching and found an 'Invalidated' RCA containing the Target scope, Target, Source scope, and Source along with the operation but the problem still persists am I looking at the wrong one or is there any other reason why even setting it to 'Allowed' the problem persists.