Quickbase Discussions

 View Only

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

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

  

Sharing Data Across Quickbase Apps: Part 2 Quickbase Pipelines, Actions, Webhooks, and 3rd Party Integrations

Last Updated on 04/04/22

One of the most powerful aspects of Quickbase 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.  
 
Quickbase applications manage data for processes, and often that data needs to be replicated, shared, or transformed. Quickbase makes it easy to replicate, transform, and share data using 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 Quickbase 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 
Quickbase Sync 
 
Part 2 
Quickbase Pipelines 
Quickbase Actions 
Quickbase Webhooks 
 

Quickbase Pipelines 

Quickbase Pipelines allow builders to perform actions on Quickbase data across applications (and realms!) either by a trigger (data added, modified, or deleted) or on a schedule and fully integrate their data across cloud-based software tools, as well as some on-premise systems. 
 

Key Benefit - Ability to create workflow with no code. Ability to connect disparate 3rd party systems without always needing to utilize an API. 

 

Pros:  

  • No coding is required 
  • Execute in real-time or on a schedule 
  • Failure logging 
  • Perform actions against another application without sharing system resources (CPU) 
  • Ability to take action(s) based on responses 
  • Connect 3rd-party systems – Quickbase is not required to be part of a pipeline! 

     

    Cons: (please keep in mind some of these will be addressed in future releases!) 

    • Visible only to user who created the pipeline (and realm admins via Switch User functionality.) 
    • No centralized error-logging 
    • No email notifications on errors 

       

      Quickbase Pipelines work well when:  

      1. You need to transform data before upserting to another table/system 
      2. You need to integrate with 3rd-party systems such as Salesforce, Jira, Box, or via an API 
      3. You need to take action(s) on a response from another action (add/delete/update action) 
      4. You want to limit application dependencies for performance reasons 

       

      Considerations 

      Don’t create infinite loops. Actions, webhooks, and triggered pipelines all execute based on a trigger. Ensure triggering one doesn’t trigger the initiator. 

      Consider the rate at which your pipelines will fire. For any app, a maximum of 20 pipelines can be triggered per second (this limit is combined with webhooks fired). If you exceed this rate, subsequent message(s) will not be sent, and no notification is made. The limit of 20 triggers per second becomes increasingly important with scripts involving a high frequency of adds, edits, and deletes that will trigger a pipeline. 

      Consider how real-time your changes need to be. You’re able to have 90 unique triggers per Quickbase table. Scheduling pipelines or utilizing callable pipelines is a scalable and efficient building pattern. Consider consolidating pipelines if they share a trigger and using logic within the pipeline to drive the workflow. 

      Schema changes can break pipelines. Pipelines do not have control over changes made to the schema. Therefore, changes to field names could break a pipeline 
       
      Set up a process to audit your pipelines. Pipelines does not currently have a notification for failures. Pipeline owners should plan to check their Activity Logs often to ensure pipelines are running smoothly.  

      You can learn more about building pipelines here. 

        
      Quickbase Actions

      Quickbase actions allow builders to automatically add records or edit related records in a Quickbase table when data is added, modified, or deleted in any table the builder has access to, including across applications. 
       
      Key Benefit - Ability to create workflow with no code 

      Pros: 

      • No coding is required 
      • Execute in real-time 
      • Failure logging 
      • ‘Add’ record actions to another app without sharing system resources (CPU) 

        Cons: 

        • No multi-step actions 
        • No ability to take action on response 
        • No ability to delete 
        • No ability to do retries on failure 
        • ‘Edit Related records’ result in app dependency and shared system resources (CPU) 

           
          Quickbase 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 triggered pipelines 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. 
           
          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. 
           
          Learn how to create actions in the Quickbase help doc here. 
           

          Quickbase Webhooks

          Quickbase 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 Benefit - Ability to send HTTP messages 

           

          Pros: 

          • HTTP messages to 3rd party services 
          • Execute in real-time 
          • Failure logging 
          • ‘Add’, ‘Edit’, or ‘Delete’ records in another app without sharing system resources (CPU) 
          • Send calls/data to 3rd party systems 

             

            Cons: 

            • No retries on failure 
            • No multi-step actions 
            • No ability to take action on response 
               

              Quickbase 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 Quickbase, 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 triggered pipelines 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 (this limit is combined with pipeline triggers.). 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 Quickbase help doc here. 
               
               
              Conclusion 
              Sharing data across apps unlocks additional 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. 
               
               
              Guidance for Determining the Complexity Level of an Application 
               
              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 application. 

              Permalink