Quick Base Discussions

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

By Evan Martinez posted 08-28-2019 13:49

  
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 between 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 we will review are:

Part 1 (View Part 1 Here)
Cross-App Relationships
Table to Table Imports
Quick Base Sync

Part 2
Quick Base Actions
Quick Base Webhooks
Quick Base Automations
3rd Party Integration Platforms



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 applications.

Key Differentiator-
Ability to create workflow with no code



Quick Base Actions work well when:
  1. You need to create a workflow that adds a record to a destination table based on adding, editing or deleting record(s) of information.
  2. You need to create a workflow that edits related records in a destination table based on adding, editing or deleting record(s) of information.
  3. You need to track the changes to a field of data over time
Considerations
DonÕt create infinite loops. Actions, Webhooks, and Automations all execute based on a trigger. Ensure triggering one doesnÕt trigger the initiator.

Consider the rate at which your actions will fire. 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, application 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 throw an error.

Setup 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.

Learn how to create Actions in the Quick Base help doc here.



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

Key Differentiator-Ability to send HTTP messages



Quick Base Webhooks work well when:
  1. You need to do real-time bulk add, edits or deletes.
  2. Builders are comfortable using web service APIs, like the QuickBase API, and are familiar with HTTP message structures.
  3. You need to send data to a 3rd party service which supports RESTful Web APIs.
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 tableid or appid 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://acme.quickbase.com/db/bnmrvfx22 would become https:// acme.quickbase.com/d/[D... TableID]

DonÕt create infinite loops. Actions, Webhooks, and Automations all execute based on a trigger. Ensure triggering one doesnÕt trigger the initiator.

Consider the rate at which your webhooks will fire. 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.

Learn more about Webhooks in the Quick Base help doc here.



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

Key Differentiator-Multi-step actions




Quick Base Automations work well when:
  1. You need to perform multiple actions with any combination of adds, edits or deletes.
  2. You need to schedule a Quick Base table-to-table import.
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 doesnÕt trigger the initiator. 

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 throw 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 fire. For any app, a maximum of 20 Automation 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 Automation messages per second becomes increasingly important with scripts involving a high frequency of adds, edits, and deletes that will trigger something.

Learn more about Quick Base Automations in the Quick Base help doc here.




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

Key Differentiator-Ability to transform data and integrate with other cloud services.



Integration Platforms work well when:
  1. You need to query a set of records, loop through the results, evaluate the data, and make decisions on what to do next.
  2. You need to transform data.
  3. You need to connect to another cloud service.
Considerations
Consider the volume, frequency and time of day your integrations will run. High volume runs should be run when application usage is low. High frequency runs should be optimized to execute quickly when application 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 trigger the initiator. 

Establish an auditing process. Over time, your application 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.


Sharing data across apps unlocks additionally value through automating processes, reducing data duplication and ensuring data integrity. With many options at your disposal, you can pick the right tool for your scenario, and ensure your apps are powerful and useful for more people. And by following the guidelines outlined here, you can ensure your apps produce the most value, and are extensible and maintainable for the long haul.





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


0 comments
15 views

Permalink