Sharing data across apps

Quick Base apps manage data for processes. When you need to replicate, share, or transform these data, you have the following seven options:

  1. Automations

  2. Actions

  3. Webhooks

  4. Integration platforms

  5. Table-to-table imports

  6. Quick Base Sync

  7. Cross-app relationships

Consider your particular data needs and the pros and cons of each option to select the one that best suits your app. Key factors to consider are your needs for immediacy, consistency, and control. The Venn diagram below shows where the different options fall according to these factors.

Key differentiators and examples

Type key differentiator examples
1. Automations Multi-step workflows, included in Quick Base platform

For an asset management use case, you could use automations to:

  • Create a work order
  • Take the asset out of service
  • Log the history of a status change in separate app
2. Actions Single-step workflows with no code

For an asset service request use case, you could use actions to

  • Track service request status history
3. Webhooks Single-step workflows with some code
  • Auto-provision an app after approval
  • Send an invitation to the designated app manager
  • Send a message via Slack to a requestor
4. Third-party integration platforms Multi-step workflows with integrations
  • Check scheduled events weekly
  • Ask Quick Base for registrants
  • Assign sessions based on interest
5. Table-to-table imports Replicate data from multiple source tables into one target table
  • Multiple project management apps
  • Different processes and workflows
  • Consolidated view of status, budget and cost across a portfolio
6. Quick Base Sync (connected tables) Ability to easily configure and schedule data replication
  • Bringing in data from a non-Quick Base app
  • Customer contact info replicated nightly
7. Cross-app relationships Ability to create one-to-many relationships between tables in separate apps
  • Pull in vendor contract terms into a PO Request app
  • Simplify the PO approval process

Pros and cons and other considerations

There are trade-offs with each option. To help you decide which one to use, review the pros and cons and considerations below.

1. Automations

Quick Base Automations allow builders to automate multi-step workflows based on the same event triggers and constraints available for Quick Base email notifications.

Pros Cons
  • Performs multi-step actions with adds, updates, deletes
  • Failure logging
  • No retries on failure
  • No HTTP messages to 3rd party services

Considerations

Consolidate multiple actions into one automation when possible

If you need to chain together a series of actions based on the same trigger or a change to a preceding action, consolidate actions into one automation.

Ensure data compatibility

When moving data from one field to another in an automation, make sure the data and field types are compatible. Data transformation is currently unsupported.

Don’t create infinite loops

Actions, webhooks, and automations all execute based on a trigger. Ensure triggering one automation doesn’t create subsequent triggers.

Schema changes can break automations

Automations do not have control over changes made to the schema. Therefore, any change to a field used in an automation can cause the automation to have an error. Owners of automations should set up a mailbox folder to capture and monitor for failures.

Consider the rate at which your automations will run

For any app, a maximum of 20 automation messages can be sent per second. If you exceed this rate, subsequent messages will not be sent and the app manager will receive an alert and an email notification that the message was not sent. The limit of 20 automation messages per second becomes increasingly important with scripts involving a high frequency of adds, edits, and deletes that will trigger something.

2. Actions

Quick Base actions allow builders to automatically add records or edit related records in a Quick Base table when data is added, modified, or deleted in any table the builder has access to, including across apps.

Pros Cons
  • No coding required
  • Basic failure logging
  • No multi-step actions
  • No ability to take action on response
  • No ability to delete
  • No retries on failure
  • ‘Edit Related records’ results in shared system resources

Considerations

Don’t create infinite loops

Actions, webhooks, and automations all execute based on a trigger. Ensure triggering one action doesn’t create subsequent triggers.

Consider the rate at which your actions will run

For any app, a maximum of 20 actions messages can be sent per second. If you exceed this rate, subsequent message(s) will not be sent and the app manager will receive an alert and an email notification that the message was not sent. The limit of 20 actions messages per second becomes increasingly important with scripts involving a high frequency of adds, edits, and deletes that will trigger an action.

Leverage markers

If it is important for the destination to know what record in the source triggered the update you can use the markers provided in the action and write the values to the destination. For example: record link, table, record name and id, app name and id.

Schema changes can break actions

Actions do not have control over changes made to the schema. Therefore, any change to a field used in an action can cause the action to have an error.

Set up a process to audit success and failures of your actions

Owners of actions should set up a mailbox folder to capture and monitor for action failures.

3. Webhooks

Quick Base webhooks allow builders to automate simple workflows or send automated HTTP messages to third party services based on the same event triggers and constraints available for email notifications.

Pros Cons
  • Craft HTTP messages to 3rd party services
  • Basic failure logging
  • No retries on failure
  • No multi-step capability
  • No ability to take action on response
  • Must be thoughtful about API calls

Considerations

Use the right API for adding, editing and deleting

When adding or editing records in Quick Base, app builders should use API_ImportFromCSV. When deleting, builders should use API_PurgeRecords. Use these API calls instead of API_AddRecord, API_EditRecord and API_DeleteRecord, to ensure your webhook can handle bulk updates.

Consolidate multiple webhooks into one when possible

When the only difference in multiple webhooks is the destination table ID or app ID and you have the destination ID stored with the triggering record, use the field with the destination ID in place of the hardcoded ID in the webhook endpoint URL. For example: https://example.quickbase.com/db/bnmrvfx22 would become https:// example.quickbase.com/db/[D...TableID]

Don’t create infinite loops

Actions, webhooks, and automations all execute based on a trigger. Ensure triggering one action doesn’t create subsequent triggers.

Consider the rate at which your webhooks will run

For any app, a maximum of 20 webhook messages can be sent per second. If you exceed this rate, subsequent message(s) will not be sent and the app manager will receive an alert and an email notification that the message was not sent. The limit of 20 webhook messages per second becomes increasingly important with scripts involving a high frequency of adds, edits, and deletes that will trigger an action.

4. Third-party integration platforms

Integration platforms allow builders to create and automate workflows across multiple apps and services.

Pros  
  • Data transformation capabilities
  • Query and looping capabilities
  • Advanced failure logging with full-featured retry capabilities
  • Take action on responses (for example, do X when request fails)
  • Not part of the Quick Base platform
  • Separate auditing process needs to be established

Considerations

Consider the volume, frequency, and time of day your integrations will run

High volume runs should be run when app usage is low. High frequency runs should be optimized to execute quickly when app usage is high.

Document all the steps involved in your integration

Platform integration tools allow multiple steps, and the logic can be difficult to follow later, even if you are the creator. Documenting the steps will help with further enhancements, maintenance, and troubleshooting.

Don’t create infinite loops

Ensure a triggering event doesn’t create subsequent triggers. Establish an auditing process. Over time, your app schema will change. It is important to ensure that changes made to the field types and drop-down values do not create unwanted behavior. Additionally, tools like Workato and Zapier provide the ability to be notified on failures.

5. Table-to-table imports

Table-to-table imports 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.

Pros Cons
  • Easy to configure field mappings
  • Large data sets execute quickly
  • Supports complex filtering criteria
  • Set up once and use when needed
  • Data is not moved in real-time
  • No warning when source or target field is deleted
  • App dependency results in shared system resources

Considerations

Use an automation to run table-to-table imports

You can set up an automation to run a table-to-table import on a schedule or when data changes.

Ensure data types are the same when mapping fields

When you configure your table-to-table import, 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 import at a desired interval.

Document the purpose of the table-to-table import and the intended field mappings

Periodically review the table-to-table imports and ensure field mapping and filter criteria still exist and make sense. The documentation and periodic review are especially useful when multiple app managers work with the schema, because field type changes and field deletions can affect the import.

Table-to-table imports create dependencies between apps when executed

Executing table-to-table imports results in the share of system resources. This sharing of system resources can become an issue with leveraging table-to-table imports for roll-up reporting across a large number of apps or a few apps that are large and complex.

6. Quick Base Sync (also known as connected tables)

Quick Base Sync connects tables to numerous cloud services, other Quick Base apps, and CSV files with SFTP servers or via cloud storage services such as Box, Dropbox, and Google Drive.

Pros Cons
  • Easily connects Quick Base tables through a wizard
  • Refreshes can be scheduled up to every hour
  • Apps can run independently without sharing resources
  • Data is read-only
  • No real-time updates
  • Refreshes use significant resources
  • Cannot do nested filtering
  • User fields are converted to text email addresses

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.

Use Sync to decouple app dependencies

Sync allows builders to easily connect tables between apps 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 use significant resources and take minutes when data sets being replicated are large. When using Sync, a best practice is to schedule refreshes during non-business hours.

Ensure the connection owner has admin permissions 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 way as any other table in the destination app, through roles and permissions.

7. Cross-app relationships

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

PROS CONS
  • Operates similar to single app table-to-table relationships
  • Real-time updates
  • Quick setup
  • Related data is not editable in the target, which means you can’t edit lookup and summary fields
  • Role setup can be complex. Beware of exposing unwanted data
  • Relationship is not visible in the source app
  • Shared system resources for both apps

Considerations

Ensure data visibility is as expected

Roles and permissions can be complex with cross-app relationships and it is important to ensure you are securing data in the way you intend. In the parent app, you must grant access to the child table. You must also assign a role for all users of the child table. Additionally, if a user has access to both apps 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 convention 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 app, you can help save a lot of time when creating or modifying reports, forms, or relationships. This convention becomes even more important as your apps grow in size and complexity.

Cross-app relationships create app dependencies

When a cross-app relationship 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 apps (10 or more apps, for example) or a few apps that are large and complex.

Determining an app’s complexity level

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

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 permissions 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 app to new builders. This is a clear indication that documentation is necessary for your app

Related Topics: