Remote Data Options for Remote Tables

  • Release version: Zurich
  • Updated July 31, 2025
  • 3 minutes to read
  • Summarize
    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 Remote Data Options for Remote Tables

    ServiceNow offers three primary architectural approaches to implementing remote tables that integrate customer and account information from external systems. These options—Full Remote, Hybrid, and Full Local—enable you to tailor data access and storage based on your business needs for real-time data access, data sensitivity, and reporting requirements.

    Show full answer Show less

    Full Remote

    This approach keeps all account and transaction data stored exclusively in an external system, providing real-time data retrieval directly from the source.

    • Use cases: Viewing customer records, relating information to cases, and obtaining a consolidated 360-degree customer view with the most current data.
    • Advantages: Always displays the latest information without storing sensitive or PII data in ServiceNow; supports real-time aggregation across multiple account types.
    • Considerations: No remote table data is available on local parent tables, which may limit some functionalities; requires updates to various ServiceNow components (forms, scripts, UI actions) to reference remote tables instead of local ones.

    Hybrid

    The hybrid model combines querying external systems in real-time with persisting select header-level data locally. This supports batch or API-based synchronization strategies.

    • Use cases: Scenarios where some data can be stored locally while still accessing real-time external data as needed.
    • Advantages: Stores only non-sensitive, infrequently changing information locally; reduces development effort with the FSO Remote Table plugin; enables current remote data presentation alongside local data.
    • Considerations: Locally persisted data can become outdated without a refresh strategy; aggregate views may not reflect the latest data until synchronization occurs.

    Full Local

    This approach fully stores all customer and account information within ServiceNow’s local tables, with periodic refreshes from the source system.

    • Use cases: When use cases prioritize reporting, dashboarding, and less frequent data updates rather than real-time accuracy.
    • Advantages: Enables faster data access and simpler Customer 360 assembly; well-suited for reporting needs.
    • Considerations: Data can become stale without refresh strategies; users may need to use separate tools to access the most current information; additional measures may be necessary to protect PII data.

    Understand the different approaches of implementing remote tables, and the advantages and disadvantages of each.

    Full Remote

    In a full remote system, all account information (accounts, insurance policies, and transactions) is stored in an external system.

    This configuration provides real-time information for customers that want financial accounts/policies to come directly from the source system when:
    • Looking at a customer record
    • Relating information to a case
    • Getting a 360 view of a customer; for example, in the Customer Information tab
    Table 1. Pros and Cons of Full Remote
    Pros Cons
    • Provides a real-time aggregate view of account & transaction information (Customer 360) for a single customer across multiple request types (for example, Deposit/Loan accounts)
    • The latest information always appears for fulfillers within the workspace
    • No sensitive data or Personally Identifiable Information (PII) is stored in the platform
    • No remote table data will be available on parent local tables, resulting in lost functionality with sold product/consumer/account
    • Updates are required on customer information (C360), record producers, forms, playbooks, reference fields, reference qualifiers, UI actions, scripts, and other areas to point from base system FSO tables to remote tables

    Hybrid

    In a hybrid system, the system utilizes lookup and save functionality to query information from external systems and persist header-level information into local tables.

    This functionality can be utilized in tandem with batches/real-time API calls to store certain data locally.

    Customer 360 is possible in this view, but it may require additional strategies around batch uploads and API calls to populate the data. You must be willing to store certain information about external data in local tables in this configuration.

    Table 2. Pros and Cons of Hybrid
    Pros Cons
    • Store only non-sensitive information in the system that is required and doesn’t change often
    • Use the base system FSO field lookup decorator to search & persist data
    • The FSO Remote Table plugin can reduce development time if used with lookup and save functionality
    • Fully remote data that is presented on the record will be current
    • Data persisted onto local tables will become outdated if not refreshed - you must have a strategy to refresh data from the external system
    • An aggregate view of financial accounts/transactions for an account or consumer won’t be shown until information has been persisted (if using lookup and save functionality) or a batch/real-time API synchronization has been performed at runtime

    Full local

    In a full local data storage architectural approach, all customer and account information (customer, accounts, insurance policies) is stored in FSO. This configuration provides faster access to information for customers who want financial accounts/policies to be refreshed from the source system on a periodic basis (daily or at regular intervals throughout the day).

    You may find this approach useful when the use case does not rely on the most recent data and prioritizes reporting needs.

    This approach helps with the following user actions:
    • Looking at a customer record
    • Relating information to a case
    • Getting a 360 view of a customer; for example, in the Customer Information tab
    Table 3. Pros and Cons of Full Local
    Pros Cons
    • Best suited for use cases that require less frequently changing information aggregate view
    • Information loaded into FSO is required for Reporting and dashboarding purposes
    • Easy to build Customer 360 for a single customer for different personas
    • Data persisted onto local tables will become outdated if not refreshed - you must have a strategy to refresh data from the external system
    • Users have to manually switch between tools ("swivel chair") for the most updated information
    • Additional solutions may be needed to secure PII data