Forum Discussion

EvanMartinez's avatar
EvanMartinez
Qrew Elite
6 years ago

How to break up cross-app relationships




Quick Base has long strived to make it easy for builders to share data. Historically, one of the most popular ways to share data has been via cross-app relationships. These relationships are incredibly simple to set up and get started with, which is great for small ecosystems. However, there are more scalable ways to optimize your data sharing. If youÕve read the article ÔHow we built Quick Base to scale and you can too!Õ (if you havenÕt, you should give it a read), youÕll know that when an application is created on Quick Base, our load balancers determine the best place for that application amongst our vast hardware and thousands of virtual environments.

But, what does that mean when you have cross-app relationships? 
Because of Quick BaseÕs unique, in-memory database, applications connected by a cross-app relationship need to share memory. The good news is Quick Base provides multiple options to share data amongst your applications. You can find two great articles discussing the pros and cons of each on the Community:

Sharing Data Across Quick Base Apps: Part 1

Sharing Data Across Quick Base Apps: Part 2

YouÕre probably now wondering how to break up cross-app relationship without disrupting your end users. There are two options available to you, depending on your data needs. The first process outlines steps to replace across-app relationship with an In-AppRelationship + Sync Table. Use this method if you do not need data changes in real-time. If you do need your data to be kept up to date on any change to the parent, use Option 2. Either change removes the application dependency, but keep your data flowing properly.

A best practice is to make these changes on off-hours to minimize any disruption for your users.

Option 1 Ð Utilizing Quick Base Sync

1.    Create a Sync table in your child application, pulling over the fields/data that you need from the parent table of the cross-app relationship.

2.    In the child table, create a formula field containing the reference field of the cross-app relationship.In the example, my Parent Cross-App reference field is named 'Related ParentCross app'


3.    Verify the formula field is populated, then edit the field type to match the type of your cross-app reference.


4.    Setup a new, In-App Table-to-Table Relationship with the sync table as the parent, and select the field created in the last step as the reference field. This will automatically link your existing child records to their new, sync table parents.

5.    Select the same fields in this relationship that you have in your Cross-AppRelationship.

6.    In your Cross-App Relationship lookup fields, under Lookup Field Options, click the Reference Field dropdown, and select the new, In-App Relationship you just created. Complete this step on each of the lookup fields. 


7.    If needed, audit the original, Cross-App reference field usage and replace it in any formulas or reports with the new, in-app reference field. 

8.    When you're satisfied the reference has been replaced, disable or delete theCross-App Relationship to remove the dependency between tables. 

Option 2 ÐUtilizing Quick Base Web hooks
1.    Create a new Parent table in the same application as your child table, with all the same fields from the Parent that you need available for the relationship.

2.    In the child table, create a formula field containing the reference field of the Cross-AppRelationship. In the example, my Parent Cross-App reference field is named'Related Parent Cross app'


3.    Verify the formula field is populated, then edit the field type to match the type of your cross-app reference.


4.    Setup a new, in-app Table-to-Table Relationship with the new in-app table as the parent, and select the field created in the last step as the reference field.This will automatically link your existing child records to their new, in-app table parents.

5.    Create a new API_ImportFromCSV webhook firing on add/update on the original Parent table. Be sure to include %RepeatOn% and %RepeatOff% to accommodate bulk add/updates to the table.


6.    Create an export .csv file of the existing records in the original Parent table, and import it into the new Parent table within the Child application that you created in Step 1.

7.    Setup a new, In-App Table-to-Table Relationship with the sync table as the parent, and select the field created in the last step as the reference field. This will automatically link your existing child records to their new, sync table parents.

8.    Select the same fields in this relationship that you have in your Cross-AppRelationship.

9.    In your Cross-App Relationship lookup fields, under Lookup Field Options, click the Reference Field dropdown, and select the new, In-App Relationship you just created. Complete this step on each of the lookup fields. 


10.  If needed, audit the original, Cross-App reference field usage and replace it in any formulas or reports with the new, in-app reference field. 

11.  When you're satisfied the reference has been replaced, disable or delete the Cross-App Relationship to remove the dependency between tables. 

12.  Ensure your webhook is active!

Written By:

2 Replies

  • When I try import the export.csv from source app to the destination app I get an error that says "Some record IDs specified were not found in this table". With this main failure point, this design pattern cannot be replicated.
  • Judging from your screenshot of the webhook, it appears that you might have created new fields to hold Record ID#, Record Owner, and Last Modified By (9, 10, and 11). This means we can probably assume that you have changed the Key of the table so that the relationship can work. I think we must also assume that this relationship is not bi-directional as we know from my previous comment that built in fields cannot be overwritten (except by stored imports). If this is the case, what happens when a user needs to add a new parent record before selecting it in the child record? Must they first go to the source app to add the new record and then trigger the webhook? This seems like poor user experience, as the user would have to know that a record must be added to the source app before they create the child record and if they didn't do it in that order, they would need to refresh in order to see the record (created via webhook) show up in the record picker.