Sharing Data Across Quick Base Apps: Part 1 Cross App Relationships, Table to Table Imports, and Sync

  • 1
  • 1
  • Article
  • Updated 4 months ago
  • (Edited)
One of the most powerful aspects of Quick Base is the ability to create many apps that can be deployed across the enterprise and accessed by a shared user base. The more apps you build and share, the more value you drive in the business. 

Quick Base apps manage data for processes, and often that data needs to be replicated, shared, or transformed. Quick Base makes it easy to replicate, transform and share data with a wide range of tools and techniques; the only challenge is choosing the right tool for the job. In this guide we will explore the various tools Quick Base provides for moving data betweeen apps. The aim is to make it easier for builders to decide which strategy works best for their need. This series of articles includes an overview, pros and cons, and considerations to assist builders in making the best choice. 

The features will will review are:

Part 1
Cross-App Relationships
Table to Table Imports
Quick Base Sync

Part 2 (View Part 2 Here)
Quick Base Actions
Quick Base Webhooks
Quick Base Automations
3rd Party Integration Platforms



Cross-app relationships provide the ability to connect two tables from different applications within a given account. They are quick to setup and follow the same pattern as relating two tables within the same Quick Base app. 

Key Differentiator-Ability to create one-to-many relationships between tables in separate apps. 


Cross-application relationships work well when:
  1. Connecting small to medium sized applications with light-to-moderate complexity.
  2. You don't need to edit the data in the destination (child) table
  3. You do need data to be immediately available on the destination table and ready for viewing on forms and reports
Considerations
Ensure data visibility is as expected. Roles and permissions can be tricky with cross-app relationships and it is important to ensure you are securing data in the way you intend. The Parent table must grant the Child table access and assign a role for all users in the Child table. Additionally, if a user has access to both applications the role in the Parent table will take precedence

Document the purpose of the cross-app relationship. Document why you are creating each lookup and summary field.

Use a consistent naming connection for cross-app fields. Understanding the source of data is especially important for builders. By developing a naming convention for lookup and summary fields, a convention which indicates the data is coming from another application, you can help save a lot of time when creating or modifying reports, forms, or relationships. This convention becomes even more important as your applications grow in size and complexity. 

Cross-app relationships create application dependencies. When a cross-app relationships is created, it results in the two apps sharing system resources. This sharing of system resources can become an issue when daisy-chaining apps or creating a hub-and-spoke structure with a large number of applications (10 or more apps, as a rule of thumb) or a few apps that are large and complex.**

Learn more about creating cross application relationships in our Table to Table relationship help guide here



Table-to-Table Imports (TTI) allow you to move data from one table into another, within the same app or across different apps. You accomplish this by defining field mappings from a source table with fields in a destination table. 

Key Differentiator-Ability to replicate data from multiple sources into one table. 



Table-to-Table Imports work well when:
  1. Connecting small to medium sized applications with light-to-moderate complexity.
  2. You need to centralize data from multiple apps into one app. e.g. for rollup reporting purposes.
  3. You need to create snapshots of data for trend reporting.
  4. You don't need the import to happen immediately when the source data changes.
Considerations

Use API_RunImport to automate Table-to-Table imports. TTIs are configured once but can be run manually whenever needed. If you would like to set up the TTI to run at some interval, you will need to leverage the Quick Base API (API_RunImport) using a script or an integration platform such as Workato or Zapier. 

Ensure data types are the same when mapping fields. When configuring the TTI, ensure your field types for source and destination match, to prevent unwanted results. (The one exception is importing a numeric into a text field, which displays the number in text form.)

Ensure you have the correct permission levels set for the destination. Once the data is imported into the destination, viewing and modifying the data follows the same roles and permissions as data entered by a user. If your intention is for the data to be read-only/not editable, be sure to configure each role to have view only permissions.

Leverage Table-to-Table Imports for trend reporting. Table-to-Table Imports allow you to configure an import to capture data over time (snapshots) for trend reporting by executing the TTI at a desired interval. 

Document the purpose of the TTI and the intended field mappings. Periodically review the TTIs and ensure field mapping and filter criteria still exist and make sense. The documentation and periodic review is especially useful when multiple application managers work with the schema, because field type changes and field deletion can affect the TTI.

TTIs create dependencies between applications when executed. Executing TTIs result in the share of system resources. This sharing of system resources can become an issue with leveraging TTIs for roll up reporting across a large number of applications (10 or more apps, as a rule of thumb) or a few apps that are large and complex.**

Learn how to create Table-to-Table Imports in the Quick Base help doc here.




Quick Base Sync connects tables to numerous cloud services including Quick Base themselves. Sync also connects to csv files via cloud storage services such as Box, Dropbox, and Google Drive, as well as with SFTP servers. 

Key Differentiator-Easily configure and schedule data replication. 



Quick Base Sync works well when:
  1. Sync refreshes are scheduled for times when there is light usage in the source and destination applications.
  2. You need a hub-and-spoke model where multiple destination tables pull data from the source.
  3. You need to keep applications decoupled.
  4. You don't need to edit the data in the destination table.
Considerations
Don’t schedule unnecessary updates. Consider the frequency of updates being made in the source and how quickly you need the updates in the destination. Your needs will help determine the refresh schedule and eliminate unnecessary updates.

Consider alternative Quick Base functionality when real-time updates are needed. Sync updates are scheduled or manually executed. When real-time updates are needed consider using other tools which trigger updates on changes in the source (such as Webhooks or Automations, outlined in Part 2). 

Use Sync to decouple application dependencies. Sync allows builders to easily connect tables between applications without sharing system resources. As such, Sync can be useful when you need to connect multiple large and complex apps with high usage.***

Schedule Syncs during low use times when possible. Sync refreshes can be expensive and take minutes when data sets being replicated are large. When using Sync, a best practice is to schedule refreshes during non-business hours /low usage.

Ensure the connection owner has the appropriate privileges in the destination. The connection to the source table is established and maintained with the credentials and permissions of the person that created the connection. The user creating the connection in the destination app must be in a role that has administrative rights. User access to the destination table is controlled the same what as any other table in the destination app, through roles and permissions.

Learn more about Sync and connected tables here

Find Sharing Data Across Quick Base Apps: Part 2 Quick Base Actions, Webhooks, Automations, and 3rd Party Integrations Here




Small with little complexity = The schema is easy to understand and navigate. You understand what is going on with formulas, roles and permissions, etc. without requiring a refresher every time you iterate the application.

Medium and somewhat complex = The schema is understandable with a small amount of studying. You need some re-grounding around what formulas, relationships, roles and permission, etc. are doing before making any changes.

Large and complex = Anytime you are working with the schema you must reground yourself or review documentation to ensure you have a solid understanding of why things were built a certain way. You find it challenging to articulate certain areas of the application to new builders. This is a clear indication documentation is necessary for your app





Photo of Evan Martinez

Evan Martinez, Community Manager

  • 12,388 Points 10k badge 2x thumb

Posted 8 months ago

  • 1
  • 1
Photo of Justin Torrence

Justin Torrence

  • 648 Points 500 badge 2x thumb
Evan,

In the Table to Table Imports Cons list, it's mentioned that:
App dependency results in shared system resources (CPU)
Does this mean that the two applications are always sharing resources?
I would expect for resource sharing to only happen while an import is happening.

Thanks in advance!
Photo of Justin Torrence

Justin Torrence

  • 648 Points 500 badge 2x thumb
That sucks, big time.

So, if I wanted information in one app to be merged into another daily, I would have to do so without a native solution in order to not have apps that share resources.

My only option is to create an API integration that will do it for me, and depending on the complexity, I may have to maintain it every time a field is added or deleted. (Assuming the app doesn't check the schema for me)

Unless I want to use Quick Base Sync. Which eliminates my ability to use the Developer Sandbox.
(Edited)
.. I was going to suggest the Sync and then table to table import from the Sync, but I gather from your post that that blocks use of the sandbox. I was not aware of that.
Photo of Evan Martinez

Evan Martinez, Community Manager

  • 11,998 Points 10k badge 2x thumb
Depending on how you are moving the data over and keeping it up to date at times Automations or Actions can be used to move the data without pulling the applications together. It is correct that a saved Table to Table Import will draw the two apps together. Due to the nature of Sync it does not line up with the Sandbox function currently. 
Photo of Justin Torrence

Justin Torrence

  • 648 Points 500 badge 2x thumb
Actually, I only need the sandbox to release a big update all at once. Sync only blocks use of the sandbox in the app that the connected table is in. So if I had an app that was only used for the sync and the import, what you suggested might work.
:) every time they give us a new tool we find more ways around our obstacles.