Remote Tables Overview
Remote tables enable you to connect your instance to third-party sources, or another instance to retrieve data. However, unlike traditional integrations, the data is not persistent (or stored in) database tables. Wait, what?! I know, I had the same reaction. "If the retrieved data is not stored in the database, then where does it go and why even bother getting it?" You may need to do this for compliance reasons, or for just a quick look at remote data. The cool part is, Remote Tables work a lot like regular tables - you can use them in lists, forms, reports, and many other basic operations. When someone accesses the remote table, an API call is made to the third party system to retrieve the information at that moment. The data is stored in memory temporarily. You may want to do this for security reasons. For example, the external data provider clearly states a phrase something like "no copies of the data shall be stored on third-party systems." You may also want to use a remote table to store temporary data like the currently logged in user's local weather. For the latter use case, the data is obsolete in a few minutes anyway, so why store it in table and go create logic to maintain it?
At this point, you may be thinking, "Remote Tables sound like a lot of API calls!" And you may be right. Here are a few things to think about before jumping in and using a remote table. Let's say you've got 100,000 customer records in a third party CRM system...
-
You're not getting all the data each time. The retrieved data lives in memory as long as the user is accessing the list or form.
-
Ask yourself "Do I need ALL the data each time?" Can you get a subset of the data? For example, if Abel Tuter is looking at a remote table, does he need (or have access) to 100K of records, or just the customers in his territory?
-
Can the data be cached for a certain time? Gather requirements, or observe, how users interact with the data. Maybe Abel's morning pattern is to make a few updates to records early in the day, do a quick customer report for 15 minutes, and then never touch it again for the rest of the day. A cache for 15-20 minutes would retrieve the data once and prevent repeated API calls.
This is meant as an overview to Remote Tables, not mean to be an entire tutorial on how to configure them. We have wonderful documentation for that.
New to the Washington D.C. release
In Washington D.C. we've introduced a way to trigger the data refresh from a Flow Designer flow. This brings several benefits:
-
Faster building and maintenance for experienced developers.
-
Enables low-coders to build and maintain Remote Tables.
-
Reusable actions, subflows, and flows.
Note: Data refresh in versions prior to Washington D.C. was done via script. This method is still available so there are no compatibility issues going forward.
As you define your Remote Table Definition (see Figure 1), you'll find a new Flow Field. If this is not populated, click the pencil icon and Flow Designer appears. If the flow is populated, the script field is automatically hidden to prevent confusion/conflict.
Figure 1: The new Flow field in the Remote Table Definition record
In Flow Designer, use the new trigger Remote Table Query, available under Application (see Figure 2.)
Figure 2: The Remote Table Query in Flow Designer
Of course, there's plenty more to the flow, such as retrieving data from the remote source. This may be done via an existing Integration Hub spoke or one you have created. Your integration could retrieve a single record, or a list of records. The key thing to know about creating Remote Table Records is the new action Global > Create Remote Table Record (see Figure 3.) Of course, if your integration retrieves a list of records, you'll need to put it inside a For Each loop to create the series of records.
Figure 3: Add records to your remote table with the new Create Remote Table Record action.
Conclusion
Remote Tables are a powerful feature when you need to comply with data storage regulations or have temporary data. Washington D.C. makes it easier for new and experienced devs to build and maintain the integrations to retrieve the information with a new field on the Remote Table defintion, new Flow Designer trigger, and new action to store data in the table.
8 Comments
