Cross-Scope Error: getDecryptedValue(client_secret) refused on custom table extending oauth_entity

[BaijunathS]

Hi everyone,

I am running into a strict cross-scope access policy error within a scoped application and would appreciate some architectural guidance or workarounds.

The Context & Architecture:-

We are building a custom scoped application and need to store OAuth credentials. To achieve this, we created a custom table inside our scoped app, and we extended the native global oauth_entity table.

Our goal was to inherit the standard OAuth fields (Client ID, Client Secret, Lifespans, etc.) while adding our own custom scoped fields.

The Issue:-

When we attempt to interact with records on this new custom table—specifically when the form loads or when the system tries to interact with the inherited client_secret field—we are blocked by the system's encryption APIs.

Here is the exact error message displayed at the top of the form:

Access to api 'getDecryptedValue(client_secret)' from scope 'rhino.global' has been refused due to the api's cross-scope access policy

Additional Details:

1. The client_secret field is a Password (2 Way Encrypted) field inherited directly from the global oauth_entity table.

2. The error specifically mentions scope 'rhino.global', which implies the underlying JavaScript engine is blocking the scoped app from decrypting a global password field.

3. We have not written any custom scripts explicitly calling getDecryptedValue(); this is happening natively via the platform UI/form rendering.

4. If we temporarily switch our active working scope in the ServiceNow UI from our custom app to "Global", the form works perfectly. The error completely disappears, and the client_secret decrypts and generates exactly as expected. The error only occurs when our active scope is set to our custom scoped application

My Questions:

1. Cross-Scope Privileges: Is there a specific sys_scope_privilege record or configuration that allows a scoped application to natively decrypt and display an inherited password field from a global table?

2. Best Practices: Is extending the oauth_entity table inside a scoped application fundamentally unsupported due to these strict cryptographic boundaries?

3. If extending the table is an anti-pattern, what is the recommended best practice for linking custom scoped data to native OAuth Application Registries?

Thank you in advance for any insights!

[Tanushree Maiti]

Hi @BaijunathS 

Refer: https://www.servicenow.com/community/itom-forum/access-to-api-getdecryptedvalue-password-from-scope-...

KB0727180 How to resolve a cross-scope access policy error when creating a record in a custom table 

https://www.servicenow.com/community/developer-forum/cross-scope-access-error/td-p/3384346

Refer:  KB0690133 How to grant cross-scope access to an application or module 

Getting the cross-scope access policy error while executing the getDecryptedValue() function from th... 

What exactly is "rhino.global", and how do I make it shut up? 

Access to api 'getDecryptedValue(password)' from scope has been refused 

Option 1: Approve via Restricted Caller Access (Recommended)

• In the Application Navigator, change your current application scope to Global.
• Navigate to System Applications > Restricted Caller Access Privileges.
• Look for a record where the Source Scope is Global  and the target is your scoped table.
• Change the Status field from Requested or Invalid to Allowed.

Option 2 (If record is not available in option1) : Manually Create a Cross-Scope Access Record

• Navigate to System Application > Application Cross-Scope Access>Click New
• Fill out the form fields with the following details:
1. Source Scope: Global
2. Target Scope: Select your custom scoped application containing the client_secret field.
3. Target Name: getDecryptedValue
4. Target Type: Scriptable or Execute API
5. Operation: Execute
6. Status: Allowed
• Save the record.

Option 3: Verify Table Application Access

Ensure the custom table hosting the client_secret field applied to all Application scopes