{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":16134,"path":"financial-services-operations/setting-up-a-remote-table-integration.md","title":"Setting up a remote table integration","bundle":null,"doc_type":null,"release":"australia","body":"\n# Setting up a remote table integration\n\nThis use case illustrates how an agent at a financial institution can access individual consumer, bank account, and transactional data that resides in a third-party external system. This integration methodology can apply across industries, such as integrating to a policy administration system in insurance.\n\n## Scenario\n\nA consumer of the financial institution calls in to get more information about a recent transaction on their savings account. The agent at the financial institution creates an interaction record while on the phone with the consumer. The agent wants to review recent transactional activity, so they populate the consumer's details within the Consumer field and save.\n\nThe Consumer field is referencing a remote table, which means the consumer’s record is being retrieved from the financial institution’s CRM tool without being stored in ServiceNow.\n\nOnce the agent selects the consumer in the Consumer field, they can see all of their related savings accounts in a separate field, labeled Deposit Account. This field is referencing account information from an external system. The list of bank accounts is filtered to the consumer’s using a reference qualifier.\n\nOnce the agent opens the consumer’s record, they can see the related bank accounts and related transactions that reside in the external system. The agent can easily find the transaction the consumer is calling about and move forward in the resolution process.\n\nThe agent creates a case from the interaction record through a UI action. The remote data from the interaction is retrieved and pre-populated on the case form.\n\n## Objectives\n\nThis use case achieves the following:\n\n- Look up an individual Customer \\(Consumer\\) from an interaction which is stored in an external system\n- Filter the list of available deposit accounts on the interaction record based on the consumer selected\n- After opening the Consumer detail page, provide a related list titled 'Bank accounts', which pulls in any Bank accounts stored in an external system for that Consumer record\n- After selecting a 'Bank account' record, provide a related list titled 'Transactions', which pulls in any Transactions stored in an external system for that Bank account\n- Leverage a UI policy to create a financial services case from the interaction record and pre-populate the consumer and bank account information populated by the agent on the interaction record\n\n## High-level setup procedure\n\nThe following table shows the steps to set up a remote table integration and display the data in the user interface.\n\n\n
\n\nStep\n\n\n\nDescription\n\n
\n\nActivate the remote tables plugin\n\n\n\nThe remote tables plugin must be enabled for the ServiceNow instance to support remote tables. For more information, see [Activate the remote tables plugin](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/servicenow-platform/activate-remote-tables-plugin.md).\n\n
\n\nInspect the source data\n\n\n\nBased on the approach you plan to take, you should determine what external data is shown in the system. The endpoints and queried source data will vary depending on your individual architectural layout.\n\n
\n\nCreate the required remote tables\n\n\n\nCreate the required remote tables so you can see the proper data retrieved from the external source.A remote table needs an external primary key to relate its temporary data to the data stored in the external source.\n\nYou should identify the data elements you want to pull from the external sources and display in your workspace. For example, when pulling Consumer information, in addition to the external primary key, you may want to include full name, country code, city, and so on.\n\n
\n\nCreate outbound REST messages\n\n\n\nSet up the outbound REST message requests to perform proper GET calls to the external system where the information is stored. Navigate to **All** > **System Web Services** > **Outbound** > **REST Messages** to do so.\n\n
\n\nCreate consumer remote table definition\n\n\n\nCreate the proper definitions where you define the script and tell ServiceNow what actions to perform when invoking each REST API call.In this step, you’ll align the values you want to display in your remote table to the values that are specified in your external system.\n\nYou also must map the sys\\_id field to the designated external primary key in the external system.\n\n
\n\nCreate entity relationships through remote tables\n\n\n\nWhen making other remote tables, create relationships between them by mapping the unique external primary key to the sys\\_id field of your remote table.For example, to relate a bank account or insurance policy to its consumer, the external primary key must be mapped to the sys\\_id field in the Consumer remote table definition.\n\nConfigure the Related Lists for the consumer to view the related records. This can be done by opening the context menu of consumer record, then navigating to **Configure** > **Related Lists**.\n\n
\n\nUpdate fields on the interaction record to reference remote tables\n\n\n\nThis step gives an agent the ability to search for the remote data when needed.Create custom fields that reference your remote tables in an interaction. This can be done by opening the context menu of the interaction record, then navigating to **Configure** > **Form Layout**.\n\n
\n\nAdd reference qualifiers on fields\n\n\n\nThis step enables filtering of the list so it only shows, for example, accounts or policies within the external system that are related to the selected consumer.For more information, see [Reference qualifiers](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-administration/c_ReferenceQualifiers.md).\n\n
\n\nCreate a UI action to populate remote data\n\n\n\nCreate a UI action to populate remote data from the interaction into the case, or the respective objects in your workflow.For more information, see [Create a UI action](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-administration/t_EditingAUIAction.md).\n\n
\n\nUtilize the FSO Lookup client action\n\n\n\nThe Lookup UXF Client action, included in the Financial Services Remote Tables plugin, is essential for setting up the FSO Lookup Client action.This action integrates the Action Payload Definition and is used within a field decorator as a UXF Client action.\n\nIt’s available as part of the Remote table lookup application but requires integration with a field decorator or a declarative action.\n\nFor more information on the FSO Look Up Client action, see [FSO Look Up Client action](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/financial-services-operations/fso-look-up-client-action.md).\n\n
\n\nDisplay remote transactions for locally stored financial account\n\n\n\nYou can choose to keep information that changes frequently in remote tables \\(such as transactions\\) while storing other data that doesn't change in local tables.For instance, you can display transactions for a persisted bank account as a related list where all transactional data remains in an external system. For more information, see [Create defined related lists](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-user-interface/t_CreateDefinedRelatedLists.md).\n\nWhen creating the relationship, specify the remote table as the **Queries from table** value. Use a function in the **Query with** field to define the relationship between the transactions and account.\n\n
For more information on the implementation walkthrough, see the FSO Remote Table setup guide.\n\n"}}