---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/application-development

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Requested restricted caller access (RCA)

# Requested restricted caller access (RCA) {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Requested Restricted Caller Access (RCA)

The Requested Restricted Caller Access (RCA) feature allows store apps on the ServiceNow AI Platform to access protected resources without waiting for a family release.
System or application admins can review, approve, or deny these requested RCAs, which are categorized into real and requested RCAs based on their scope.
Show full answer Show less  

## Key Features

* **Real RCA:** Matches the application scope with the target scope.
* **Requested RCA:** Awaiting approval, where the application scope does not match the target scope.
* Scheduled jobs generate RCA records upon application installation, with "Requested" status for each package in the source application.
* Developers can generate RCA privileges and synchronize requested RCAs with real RCAs during application development.
* Administrators receive notifications for pending RCA reviews on application pages.
* Backward compatibility ensures store apps can be packaged with Allowed status for pre-Rome instances.

## Key Outcomes

By utilizing RCA, ServiceNow customers can streamline the approval process for app resource access, ensuring applications function correctly across versions. This also enables developers and administrators to manage and review access requests efficiently, enhancing overall application performance and compliance.  
You can use a requested RCA to grant store apps access to protected resources in the ServiceNow AI Platform without the need to wait for the next family release. If you have the system
admin or application admin role, you can review requested RCAs and approve and deny
them.  
RCAs are classified into two categories:

* Real RCA: sys_scope==target_scope
* Requested RCA: sys_scope!=target_scope
{#requested-rca__ul_qd3_dsn_1qb}For example: A real RCA record is where the application scope and target scope match. A requested RCA is a record that is still awaiting approval for access to the target scope.  
When you install an application, your scheduled jobs generate RCA records with the status of Requested in the target application for each requested RCA record that is packaged in the source application.  
Note:  
The jobs are generated once Upgrade Summary has run.

## Example of how a store app accesses a table {#requested-rca__section_e2q_2fd_gqb}

Let's say that a store app called HR Integrations Framework wants to access an HR Core Case
table. The table is in the business rule called Find Case in the Integration Service table.  
To request access, the HR Integrations Framework app requires that an RCA privilege is packaged in its own scope as follows:

* sys_scope = HR Integrations Framework
* target = HR Core Case
* status = Allowed
* target_scope = Human Resource: Core
* source = Find Case
{#requested-rca__ul_jk1_1yn_1qb}

## App development example for developers {#requested-rca__section_ahv_tzn_1qb}

When you are developing an application, real RCAs are generated with the status of Requested
when the target has a caller restriction. If the target has caller tracking, the status becomes
Allowed. The developer can review and finalize all the real RCA records that are required for
the application to work. For example, those RCAs with a status of Allowed.

A developer can click the Generate RCA Privileges in Current App in
the related links to generate requested RCAs that are packaged in the current application.
Requested RCAs are synchronized with real RCAs, which means that if a real RCA is updated or
deleted, a requested RCA is updated or deleted too.

Now, the HR Integration Framework application can be packaged and installed on a customer
instance.

## App installation example for administrators {#requested-rca__section_kqv_3d4_1qb}

When you are installing an app on a customer's instance, real RCAs are generated in the target
application. A real RCA would have the Human Resource: Core with a status of Requested. This
process is done asynchronously in a scheduled job, where some lag time can occur.  
To notify the target app admin about an RCA's pending review, messages have been added to application pages. An example is as follows: Figure 1. RCA pending review message

## Store App backward compatibility {#requested-rca__section_hcs_jgt_2qb}

If a store app is compatible and can be installed on an instance that is pre-Rome, then you must package the RCA records in their own scope with the status of Allowed.  
Note:  
This process ensures that the store app works on all versions.

When upgrading to Rome, you can configure a one-time fix script to move RCAs in the source
scope to the target scope. In Rome, if the target app already has the necessary RCA records, no
RCA records are generated for the RCAs that are packaged by the source app.