Extending Quick Base

This topic provides information about supported and encouraged approaches, design patterns, and security considerations while extending Quick Base.

Overview

Quick Base provides a powerful platform for no-code and low-code development, providing you with real-time insights into work processes that can be customized, updated, optimized, and automated in many ways.

Quick Base solutions often provide more value when part of an ecosystem, extending the customization and insights to other systems. When solutions need additional customization or integration, Quick Base offers a rich set of APIs to enhance the platform. Your organization may extend the platform or work with our certified Quick Base Solution Providers (partners).

Important: All uses of Quick Base must comply with any applicable agreements and individual feature restrictions, such as Everyone on the Internet (EOTI). Building solutions that intentionally circumvent Quick Base licensing is strictly prohibited. Quick Base does not control the third-party systems you may integrate with using our APIs and has no control over or responsibility for your data once the data leaves the Quick Base service. We recommend you undertake due diligence on any licensing, security or other restrictions these third parties may have.

General scalability

Quick Base utilizes edge-layer protection with Cloudflare to ensure security and stability of the platform. Quick Base may return an HTTP error 429 in the case where an integrator is making too many requests in a period. Per the RFC spec, integrators should respect the 429 response code and the response header "Retry-After" that indicates how long the originator should wait before trying again.

Internet communication is not perfect and transient faults should be expected. No platform can guarantee 100% communicative round-trip responses, as messages can break down at many different layers, some outside the control of the builder or platform. Builders should instrument their solutions with rich logging, and use API retries with exponential backoff in the case of unpredictable failures.

Server-side integrations

Server-side refers to any solution that is hosted outside of the Quick Base environment and does not run inside of the browser as a client-side solution. Generally, these solutions live and are initiated solely outside of Quick Base. Hosted may refer to servers or serverless environments owned, operated and/or maintained by your organization, services procured from a Quick Base partner or service provider, point solutions that have integrated with Quick Base, or an Integration-Platform-as-a-Service (iPaaS).

Examples of hosted environments include:

  • Colocated servers

  • On-premises servers

  • A virtual machine (VM) running a solution hosted in a cloud Infrastructure-as-a-Service (IaaS) such as Google Cloud Platform, Microsoft Azure, or Amazon Web Services (AWS)

  • Serverless utilities, such as Azure Functions, that are capable of initiating HTTP calls

Most commonly, solutions running on a server are an integration, connecting two or more systems to transfer information back and forth. For these solutions, service account credentials (for example, quickbase_api@example.com) with access to the necessary application must be securely stored on the server or in an accessible key store.

Server-side integrations have several advantages, and some potential disadvantages. A builder’s approach and strategy to the application architecture may be informed by the advantages and disadvantages of server-side integrations, internal guidelines and other outside factors.

The advantages of server-side integration include:

  • Durability: Solutions running on a server can scale better, with more capability to control error handling and retries. They are less prone to crashing or interrupts due to factors such as computer instability or Internet issues, which can occur when the solution runs in a browser.

  • Performance: Client-side enhancements are limited to the performance of the user’s browser and computer they are running in. When running on a server, more computing resources are generally available.

  • Security: Server-side solutions are far more secure when dealing with elements such as authentication, secrets, and tokens. Storing a username and password in a place that will be referenced by a browser is insecure and can easily be compromised.

Potential disadvantages of a server-side solution include:

  • Cost: In general, server-side solutions are more time consuming and expensive to set up.
  • Maintenance: Server-side solutions require an environment to run on, which may include additional requirements such patches and access control.
  • Speed: Depending on the workflow, additional network hops may introduce latency.

Examples

This table includes examples of extensions involving Quick Base:

Example

Hosting

Description

Custom data integration

Your organization

ACME Corp wishes to integrate Quick Base with a legacy ERP system. An engineer at ACME Corp writes .NET/C# code that is hosted locally in the same environment as their ERP system. This code is owned and maintained by ACME Corp and makes API calls to Quick Base to send/receive data before/after communicating with the legacy ERP system and doing the necessary data transformations.

Partner Dropbox integration

Partner

ACME Corp wishes to add value to their workflow by integrating Quick Base and Dropbox. A Quick Base partner offers a productized add-on that can be purchased and configured for this add-on. The integration code is hosted, run and maintained by the partner.

Zapier QuickBooks integration

Zapier

ACME Corp creates invoices in Quick Base and would like to have them sent to QuickBooks Online. Zapier has a connector to both Quick Base and QuickBooks and configure the necessary Zap. The integration code is hosted, run, and maintained by Zapier.

Formstack Documents integration

Formstack Documents

Formstack Documents provides a connector to Quick Base to deliver merged documents to or retrieve information from Quick Base in order to populate a document. ACME Corp has a Formstack Documents account and wants to generate sales documents with Formstack Documents from their Quick Base Opportunities table. The integration code is hosted, run, and maintained by Formstack Documents.

Security and scale considerations

When using a service solution such as an iPaaS or SaaS platform, you should review the security practices of those products to ensure they meet the needed levels of security and compliance for your organization. Even with stringent security standards in place, you must make use of good practices, such as tokenizing, securing, and rotating credentials, and not hard-coding them.

When creating custom solutions, builders should consider authentication and encryption practices that meet industry standards and additional compliance and security needs based on their respective regulatory or company policies. Some of these practices include, but are not limited to:

  • Only connecting to and using TLS endpoints that use modern protocols.
  • Encrypting sensitive data in storage and in transit.
  • Restricting access to code and data based on the least-privilege principle.
  • Where possible, not storing credentials. If storage is required, use modern encryption.
  • Passing sensitive, private, or regulated information into the POST body instead of URL string parameters.

Portals

A portal is an example extension where a user interface reads and writes data to Quick Base. This may be used in cases where the needed workflow is specialized, streamlined, and custom, commonly embedded in a company’s website

For appropriate security, this scenario should only ever be performed using server-side techniques. Authentication is needed between both your organization’s server and Quick Base, and between the end user’s browser and the web site hosted on the server.

Your organization is responsible for the security of all server-side integrations, including portals, and how the data is read from and written to Quick Base.

Here are examples of portals involving Quick Base:

Example

Description

Doctor’s office with patient scheduling

Pete’s Podiatry uses Quick Base as their patient management system. They manage patients, scheduling, billing, and other operational functions inside of their Quick Base apps. They would like customers to be able to schedule appointments on their web site. Patients enter their last name, date of birth, and last 4 digits of their Social Security number (SSN) to view a list of available appointment slots, add a new appointment, or adjust one they previously scheduled.

Satellite repair appointment confirmations

ACME Corp performs repairs on residential satellite dishes. When a homeowner calls technical support, that case is entered into Quick Base by the representative. If a service request is needed, the phone rep converts the help case to a service request. An email notification is sent to the customer including a link to a web site where the customer can change or cancel the appointment. The link includes a GUID to reference the appointment record in Quick Base. No personal information is available to read or write on this web site.

In portal use cases like these, the external users are not authenticated with, interacting with, or aware of Quick Base. For all portal implementations and uses of Quick Base:

  • A separate, licensed service account is used for each portal implementation. This account must not be shared with any other server-side utilities, custom integrations or iPaaS tools. For example, if a customer has implemented 3 portals, they must have 3 unique service accounts.
  • The portal meets all security standards provided by Quick Base and by other industry/organization regulations and guidelines.
  • Information sharing from Quick Base to non-authenticated portal users is limited, specific, and non-sensitive. Personally-identifiable information (PII), health information, or financial information should not be presented to the non-authenticated user.
  • An authenticated user must be a discrete individual and non-generic user.

Use cases that fall outside these definitions should be discussed with the Quick Base account management team. Note that all implementations of a portal must respect and adhere to the individual contract, account entitlements, and restrictions.

Client-side enhancements

Solutions written to run inside a browser are generally faster to create, maintain, and deploy, though they generally cannot be as complex.

For low-traffic uses, code can be stored in Quick Base code pages. Low traffic is defined as needing 4 requests or less per second for all the combined resources in a given application. For higher traffic needs, you should store this code on a content delivery network (CDN) or implement browser caching to minimize page queries.

Because of the nature of client-side enhancements, all code is stored on a server, but run locally inside of the user’s browser executing the action, script, or interface. Quick Base only allows JavaScript to be inserted into code pages. Supported methodologies for referencing (or calling) these code pages are:

  • Creating a formula-URL or formula-rich text field
  • In a button on an app home page
  • Using an embedded web widget/iframe on an app home page

Examples

Here are examples of client-side enhancements involving Quick Base:

Example

Description

Time card approval

ACME Corp has employees submit weekly time cards. Upon submission, a manager needs to review the time cards and have a small custom interface to display analytics on the employee. Pressing the button writes multiple records back to Quick Base.

The builder can create a formula-url button with a formula similar to:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=99&rid=" & [Record ID#]

Page 99 is an example reference to an HTML code page with the custom styling needed and includes references to the JavaScript logic. The JavaScript reads the "rid" parameter from the URL to perform the associated queries to Quick Base.

Custom calendar

ACME Corp is looking for a custom calendar view beyond the native capabilities of Quick Base reporting. They intend to have highly visual and custom branding with a tailored workflow specific to this use case. Using an app home page with a button bar or web widget, this custom code page can easily be displayed.

ZIP code radius search

ACME Corp schedules site repairs and manages logistics with a Quick Base app. They often need to cross reference addresses of known subcontractors with the addresses of customers looking for a repair. On the Opportunity record inside of Quick Base, they push a button to launch a custom interface and perform this analysis.

The builder can create a formula-url button with a formula similar to:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=88&rid=" & [Record ID#]

Page 88 is an example reference to an HTML code page with the custom styling needed and includes references to the JavaScript logic. The JavaScript reads in the "rid" parameter from the URL to perform the associated queries to Quick Base to find the customer’s ZIP code. This information can then be used to query a third-party service with the source ZIP code and other necessary parameters such as the tolerance of radius in miles. The ZIP codes returned from the other service can then be used to query Quick Base for matching subcontractors.

Warning: Quick Base cares deeply about the security and reliability of the platform. To that end, the following techniques are unsupported and may put applications and organizations at risk for security breaches and reduce the manageability of applications. Quick Base teams cannot support these techniques.

Unsupported techniques

  1. Implementations that leverage unpatched bugs or vulnerabilities to inject JavaScript into places not specifically defined as allowed, or to manipulate Document Object Models (DOMs).
  2. Sniffing network traffic to rely on Quick Base-internal API calls.
    • Publicly-supported and maintained API calls begin with the prefix API_. Any other prefix denotes an API call that Quick Base does not provide support for, may be deprecated, or removed without customer notice.
  3. Observing and depending on Quick Base client functions such as DoSave() for custom implementations, except where noted or documented by Quick Base.
    • These functions may be deprecated or changed without customer notice.

Quick Base cannot regression test for these methods and application functionality may break without notice or support from Quick Base. Builders are encouraged to report security vulnerabilities in accordance with guidance on how to responsibly report a security issue.

Solutions that combine server-side and client-side technologies

Solving for certain scenarios may require a solution that is initiated client-side (such as a button press) and leads to a server-side dependency. In these scenarios, there are two different authentication models possible.

  1. Stored service account (for example, quickbase_api@example.com) credentials.

    1. You might need this type of solution when you want a user to initiate an action that requires elevated privileges beyond what the authenticated user has access to do, such as delete records, even though the signed-in user does not have privileges to delete.

    2. All record modifications and accountability are tied to the service account, rather than the user that pushed the button.

    3. To meet minimum security standards, access to the solution should be restricted using common security practices. As many of the following approaches as possible (based on business logic and requirements) are recommended:
      1. IP address filtering

      2. Single sign-on (SSO)

      3. Validating Quick Base sessions client-side before providing access to resources

  2. Temporary authentication passed from the client.

    1. No server-side credentials are stored. This reduces an attack vector because no credentials can be compromised from a server.

    2. All permissions, record modifications, and accountability are tied to the user pressing the button.

Example using both options

ACME Corp regularly has insurance billing agents scan approval and denial letters into Quick Base and associate them with patients. In certain cases, depending on the scanner’s configuration, multi-page files are uploaded individually as separate files. Rather than manually downloading and merging these files, their line of business worked with their internal IT team to develop an extension to Quick Base.

Server side

The builder creates a button in a formula-url field on the patient record. This field is configured with a formula like:

"https://acmecorp.example.com/mergepdfs?qbrid=" & [Record ID#]

When pushing this button, code written by ACME Corp’s IT team launches a custom interface hosted in their corporate Azure environment. It has a custom interface that queries Quick Base based on the Record ID# passed in the URL, using the stored credentials on the server. The user then selects the files they want to merge into one. The code in Azure downloads the files from Quick Base and then uses a library that ACME Corp’s IT department has licensed and approved for use. This library merges the files together, returning one PDF which is ultimately written back to Quick Base. This file has a record owner of "ACME API." For security, any temporary files stored locally on the server are deleted automatically.

Client side

The builder creates a button in a formula-url field on the patient record. This field is configured with a formula like:

URLRoot() & "db/" & AppID() & "?a=dbpage&pageid=77& "&rid=" & [Record ID#] 

When pushing this button, a Quick Base code page is launched. It retrieves a temporary authentication token and performs an HTTP POST and redirect to the following:

"https://acmecorp.example.com/mergepdfs?qbrid=" & [Record ID#]

This passes in the temporary authentication ticket. The user experience and core logic are the same as the above. The file ultimately created has a record owner of the user who pressed the button.

Development process

Builders should follow best practices for the development, maintenance, and change management of Quick Base enhancements. Code should be maintained in a suitable source code management tool. Testing should include unit, integration, and regression test cases. Builders should have clear separation of duties and appropriate controls and approval chains for releases or changes.

Support

Unless noted otherwise, Quick Base does not provide support for custom code, external solutions, or custom hosting, however, we will provide technical support, architecture overview, and guiding principles for the API calls that interact with Quick Base. Builders looking for assistance should capture the raw (XML, JSON) request/response from their tool set and the Quick Base API call being used when opening a case with Quick Base Customer Care.

Important: Always be sure to obfuscate or remove authentication and any other sensitive information before providing logs to any external party, including Quick Base Customer Care.

Involving third parties

When third-party SaaS solutions are involved, support should generally be routed to the service that is returning or providing the error or behavior needing investigation. If another service needs clarification or assistance on Quick Base APIs they are integrating with or platform details, Quick Base will gladly assist.

Support examples

Scenario

Level 1 support or initial system to investigate

Using a webhook to a legacy ERP system. The system is returning an authorization error as discovered in the Quick Base webhook error history.

Developers of the ERP system to explain authentication protocol.

Sending a webhook to a legacy ERP system. Evidence suggests the webhook is not leaving the Quick Base app.

Quick Base to determine if and why the webhook is not being sent from Quick Base. If the webhook is being sent, Quick Base will provide the necessary information for customers to contact the ERP developers to investigate why it is not being received.

Using Formstack Documents to create documents and have them uploaded to Quick Base after creation. The document/record is not showing up in Quick Base when expected.

Formstack Documents to investigate if the API call is being sent to Quick Base and/or if an error is being received. If an error from the Quick Base API is being returned, Quick Base Customer Care can assist.

Using Workato to receive new customers from Salesforce and create them in Quick Base. The data being written to Quick Base appears to be inconsistent with what is in Salesforce.

Workato to determine if the proper configuration is present to transform the data between Salesforce and Quick Base data types. Investigation may lead to Salesforce to find out why certain data is not being returned or Quick Base to format data as expected for the Quick Base API or individual application.

Creating a custom JavaScript interface that is launched when a button is pressed to approve timecards. This page is popping up but not loading.

The developer of the custom code page. If API calls are failing to Quick Base, the developer can troubleshoot and open a Quick Base Customer Care case for API assistance.