Resource Icons
Latest Highlights
Check Out The Latest in The Qrew
What a couple of days EmpowerPro 2025 gave us...
EmpowerPro 2025 brought the heat with new ideas, big product reveals, and tons of inspiration. From AI that builds apps out of messy spreadsheets t...
8 days ago
1 MIN READ
We know your time is valuable, and we never take it for granted when you choose to spend it with us. That’s why we’re always looking for ways to make your experience smoother, faster, and more enjoya...
4 days ago
2 MIN READ
One registration covers all three events — join the product team for a community style Q & A session, and share feedback on features launched at EmpowerPro.
After the recent launch of ou...
10 days agoThe Content Feed
Feed
Jinja If else statement syntax
In case anyone else is looking for a solution to entering a conditional statement into a Pipeline as an out put value, here is what I learned today. Below is the syntax entered into the place where the {{ c.values }} are put in the Pipelines Designer page. If anyone knows what these inputs are named please tell me. {% if step.fieldname is gt(0) %} {{step.fieldname * -1}} {% else %} 0 {% endif %} Explanation: The statement above is an if : else statement. {% %} these things signify the conditional statement part and {{ }} these are the values the field gets if the condition is met. If the fieldname is greater than 0 {% if step.fieldname is gt(0) %} then enter the value from fieldname from a previous step times negative 1 {{step.fieldname * -1}} else do the next thing, which in this case is enter 0 into the fieldname from a previous step {% else %} finally end the if statement {% endif %} I looked around and couldn't find anything useful so here's a little nugget. ------------------------------ Jim Harrison transparency = knowledge + understanding : The Scrum Dudes ------------------------------Introducing New Quickbase Navigation (beta)
Update: This blog was initially published ahead of our open beta in May. On October 1st, new (or sidebar) navigation will become the default Quickbase experience. To help guide the transition, if your users tried new navigation during the open beta and reverted to legacy navigation, we will respect their current settings. Your team will still have the option to use to legacy (or top) navigation through the end of 2025, but doing so will require action from both admins and individual end users. Access the End User Guide for More Details > Quickbase is the world’s first platform for dynamic work management. And that means we wake up every day asking ourselves how we can make our customers more efficient and help them grow. We are continually improving the platform and adding new capabilities, so it is easier than ever for you to see, connect, and control your most complex processes. To do that, we want to make sure we continue to focus on providing an intuitive, clean user experience, which is the foundation on which the rest of Quickbase relies. That’s why we’re excited to announce the beta version of our new navigation. Here’s what to expect from our new navigation, and how you can try it out today. What’s changing? We rebuilt Quickbase’s navigation from the ground up to provide a more modern and intuitive experience for both you and your users. And, while we have future plans to add new functionality and concepts to our navigation, we’re not adding any new elements just yet. Instead, this initial release of our new navigation will re-arrange the components you use to navigate around your apps today. This approach will ease you and your users into this experience and make it easier to manage this change. Tables have moved to the left side Some may call it clunky; others call it dated, but we heard loud and clear from many of you that the Quickbase menus at the top of the page take up too much room. That’s why we’re moving app-level links to a new sidebar which you can find at the left edge of the page. Here, you can navigate to each table in your app. And if you are an app admin, you will find links to app settings and the user management page. We’re also providing centralized access to all your table settings with Settings for each table directly in the content menu are designed to save you time and clicks. It’s important to note that your existing table order and permissions will translate 1:1 from legacy navigation to the new style, so you’ll be able to hit the ground running without the need to re-calibrate your settings. With more room to breathe, you can see – and understand - more of your own data on your screen at once. There are several ways you can choose to interact with this menu, depending on how you like to get work done. You can open the sidebar by clicking the arrow to push content and maintain your open/closed state as you navigate across pages or simply hover anywhere over the closed sidebar to open temporarily and close automatically as you navigate. Switch between apps using the new global nav menu We’re cleaning up the experience of having to switch between apps with the app bar, by moving these controls to the top-left corner of the page. In this new waffle menu, you’ll be able to switch between apps. This is also where you will access other parts of Quickbase outside of apps, such as Pipelines and Exchange, enabling one-click access to key areas of the platform. Getting involved in the beta program Want to be one of the first to get your hands on the new nav? Your valuable feedback is pivotal to shaping our platform. Register here! Next steps The new navigation will be available for all users starting on May 8, 2024, with the ability to try it defaulted on. Each account admin can choose to disable the new navigation for their users under the Admin Console-> Permissions menu. If a user’s ability to turn the new navigation is not disabled, they can visit their user preferences and select sidebar navigation to try out the new experience. Happy navigating!Using ""&z=""&Rurl() and rdr in formula URL fields
People ask all the time, "What is the "&z="&Rurl() inside some of my Quickbase buttons?". Well, not all the time, but often enough that we should talk about it. I am referring to formulas that are inside Formula - URL field buttons like, "Add Task", "Add Document" or "Add Project". It doesn't matter if records are child or parent records you are creating. Only that you are leaving one location to manually add or edit a record and you wish to return back to the location from which you started. Workflows that require user input When creating a relationship, Quickbase automatically generates an "Add Record" Formula - URL field. This provides a quick way for users to create a child record. However, many people have edited their Add Record button and figured out that the "&z="&Rurl() seems to return them back to where they started from, but when they try using the function in other formulas it doesn't work all the time. The reason - it's not supposed to. This function was an expedient way for Quickbase engineers to pass a bread crumb from the originating URL into Quickbase so that when you were finished adding or editing a record you would have a way to return to your original starting point. There are two valid use cases for "&z="&Rurl(). One is when you use the API_GenAddRecordForm and the other is when you use the a=er function to edit a record. Bear in mind that both of these cases expect you to manually modify a record, save the record and return back to the URL from which you started. Here's an example using API_GenAddRecordForm: URLRoot() & "db/" & [_DBID_TASKS] & "?act=API_GenAddRecordForm&_fid_48=" & [Record ID#] & "&_fid_8=" & [Est Start Date] & "&z=" & Rurl() And here's an example using a=er: URLRoot() & "db/" & Dbid() & "?a=er&rid=" & URLEncode([Record ID#]) & "&dfid=12" & "&z=" & Rurl() The thing to remember about the above two examples is that you are starting from one spot, either adding or editing a record, manually saving the record and returning to your starting spot. The "&z="&Rurl() only works in this situation. Workflows that do not require user input If you are using another API call such as API_AddRecord or API_EditRecord, the format for redirecting to another page is a bit different. In this case, you can redirect the final API call in your formula to an a=doredirect URL. This takes the z=rurl() concept and makes it more valuable, since it allows you to make one or more API calls, and then reload the current page. For example: URLRoot() & "db/" & [_DBID_TASKS] & "?a=API_EditRecord&rid=" & [Record ID#] & "&_fid_7=Approved" & "&rdr="&URLEncode(URLRoot() & "db/" & Dbid() & "?a=doredirect&z=" & Rurl()) On the other hand, rdr can be used to redirect the user to a specific page. For example, after a new record is created, perhaps you want to display a "thank you" rich text page you've created. This thank you page should appear as the next step in the workflow, regardless of whether the user was on the app dashboard before they created the record, or whether they came from the table home page. For example: URLRoot() & "db/" & [_DBID_TASKS] & "?a=API_EditRecord&rid=42&_fid_7=Approved"&"&rdr="&URLEncode(URLRoot() & "db/" & Dbid() & "?a=dbpage&pageID=30") For more information on creating formulas in Quickbase you can review the documentation below, or open a support case for assistance. Further Reading: Using Formulas in Quickbase Formula Functions Reference Read about GenAddRecordForm in the API Guide Read about AddRecord in the API Guide Read about EditRecord in the API Guide
SAML Public Authentication Certificate for Signed Authn Requests
June 21st, 2024 Update: We have created a Quickbase app to host the Quickbase SAML Zip File. Access the app by clicking the link above to download the file. For Quickbase Realm and Account Administrators As a Quickbase Realm or Account Administrator, you are probably aware of how your users authenticate (login) to the Quickbase platform. Many Quickbase customers use our SAML authentication feature. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services, such as Quickbase, that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. To help you understand what you may be using at your company, some examples of SAML, SSO or IdP (Identity Provider) vendors are Okta, OneLogin, Microsoft, Duo, and there are many others. Some customers using the SAML authentication feature may also choose to use an extra layer of security whereby each authentication request from the Quickbase platform to your company’s SSO directory (or IdP) is signed by Quickbase using a public authentication certificate configured on the Quickbase platform. Quickbase refers to this extra security feature as the “SAML Authn Requests” option. It has that name because there is a feature in the Quickbase SAML configuration settings named “SAML Authn Requests”. Only Quickbase staff can see this option or change it. It is only enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. *When the “SAML Authn Requests” feature is enabled by Quickbase, and the customer has configured their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process, both Quickbase and the customer’s IdP must use the same public authentication certificate in order for Quickbase authentication to work successfully. If they do not match, Quickbase authentication (logins) will fail and the customer will be unable to use Quickbase. Once a year, Quickbase is required to rotate the public authentication certificate. The certificate rotation will occur on a specific date/time within a 15 minute maintenance window. Therefore, the certificate rotation process requires careful coordination between Quickbase and all customers who have chosen to use the “SAML Authn Requests” feature. Typically, about 2 weeks prior to the annual rotation, Quickbase will communicate to Realm and Account Administrators for customers using the “SAML Authn Requests” feature via in-product messaging and possibly also e-mail. We also post a notice on the Quickbase service page. We provide a link to this Community post which specifies in a section below the date and time of the rotation and provides a link to download the new public authentication certificate. *The Realm and Account Administrators need to contact the person or team at their company responsible for administering their IdP/SSO/SAML system, typically their IT department, in order to ensure that the new public authentication certificate from Quickbase is also installed in the customer’s IdP/SSO/SAML system during the 15 minute maintenance window announced by Quickbase. *The public authentication certificate CANNOT be changed in your company’s IdP prior to the announced maintenance window or logins to the Quickbase platform will break. If the certificate is not changed in your company’s IdP during the 15 minute maintenance window announced by Quickbase, logins to the Quickbase platform will be broken until the certificate is updated in the IdP. For Single Sign-On (SSO) or Identity Provider (IdP) Administrators: PLEASE NOTE: The remainder of this Quickbase Community post is highly technical and should be reviewed by the person or team responsible for administering the Single Sign-On (SSO) or identify provider (IdP) system used to control access to the Quickbase platform. Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials (username and password). An identity provider (IdP) system is a directory of usernames, passwords, groups, roles, etc. that is typically used to manage access to the applications used by a company. Another acronym commonly associated with Single Sign-On is SAML. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. Many customers use Quickbase's SAML authentication feature. A subset of customers may have the “Signed Authn Requests” option selected in their Quickbase SAML configuration. That option is a security enhancement that results in Quickbase signing the authentication requests made to the customer’s identify provider (IdP). Use of this option also requires the customer to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. *Customers who choose to use the “Signed Authn Requests” option and enable signing of authentication requests on their IdP must be prepared to manage the annual public authentication certificate update process described below. The option itself offers only marginal security benefit so customers should decide for themselves if that marginal security benefit is worth the effort required to coordinate and execute the update of the certificate and potentially incur several minutes or more of down time for their use of the Quickbase platform while the public authentication certificate on their IdP may not match the certificate used on the Quickbase platform. The “Signed Authn Requests” option is only visible to Quickbase staff and can only be changed by Quickbase staff. It should only be enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. In order to validate that the signed authentication requests actually come from Quickbase, we provide the customer with a public authentication certificate. Customers using the “Signed Authn Requests” option must ensure their IdP is configured with the public authentication certificate currently being used by the Quickbase platform to sign authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If the public authentication certificate configured in the customer’s IdP does not match the public authentication certificate being used by Quickbase, the customer will not be able to authenticate successfully to the Quickbase platform. *Quickbase has no ability to know if or how a customer has configured their IdP. We therefore cannot tell a customer if their IdP is requiring Quickbase to sign authentication requests and we cannot tell a customer if the public authentication certificate Quickbase is using matches the certificate the customer has configured in their IdP. Quickbase rotates the public authentication certificate every year and distributes it to applicable customers inside a certificate file via this Quickbase Community post. Quickbase determines the applicable customers based on which have the “Signed Authn Requests” option enabled in their Quickbase SAML configuration. During the period of time starting on the date that we announce our intention to update the certificate, and ending after the date/time we actually update the certificate on the Quickbase platform, we make both the current and new certificates available in this Community post. After we update the certificate on the Quickbase platform, we then remove the now out-of-date certificate from this Community post. Prior to the annual public authentication certificate rotation period, Quickbase will communicate via in-product messaging and possibly also e-mail to Quickbase realm and account administrators at the applicable customers the specific date/time on which we intend to update the certificate on the Quickbase platform. When Quickbase updates the certificate, we do so during a 15 minute maintenance period on the announced date/time. We strive to provide customers with enough notice of this maintenance period for them to notify their responsible staff, typically their IT department or whichever group within the customer’s organization is responsible for administering their identify provider (IdP) system. The customer’s IdP administrator should plan to update the public authentication certificate provided by Quickbase during the 15 minute maintenance period announced by Quickbase. Doing so will minimize the chance of the customer experiencing any interruption of their use of the Quickbase platform. PLEASE NOTE: For any customer using the “Signed Authn Requests” option, i.e., requiring signing of authentication requests made by the Quickbase platform to the customer's IdP, any time the public authentication certificate used by Quickbase does not match the public authentication certificate configured in the customer's IdP, logins to the Quickbase platform will fail. It is therefore essential that the customer update the public authentication certificate in their IdP during the 15 minute maintenance period announced by Quickbase annually. Quickbase Public Authentication Certificate Rotation Maintenance Window Quickbase plans to update the public authentication certificate on Wednesday, November 20, 2024, between 8:00 PM and 8:15 PM Eastern US Time. Current and New Public Authentication Certificates The NEW public authentication certificate is provided below for you to download and install on your identify provider during the 15 minute maintenance period. The zip file contains both the metadata (with certificate contained inside) as well as the certificate on its own. Current Certificate (Expires November 24, 2024): QB_SAML_Exp11-24-2024.zip NEW Certificate: (Expires November 25, 2025): QB_SAML_Exp11-25-2025.zip Additional Information on SAML Public Authentication Certificate Configuration Scenarios and Expected Outcomes This section describes several scenarios that could exist specific to a Quickbase customer using SAML authentication for access to the Quickbase platform. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform will work normally assuming there are no other SAML configuration issues. There is no use of public certificates in this scenario. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed and Quickbase is not signing them because the “Signed Authn Requests” option is disabled. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will work normally because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the currently applicable public authentication certificate and Quickbase is signing them with that same public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has a public authentication certificate installed in their IdP that is either expired, or does not match the public authentication certificate currently being used by Quickbase. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the public authentication certificate they have configured in their IdP and Quickbase is signing them with a different public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform may or may not work normally depending on the IdP and how it handles a signed request. Quickbase cannot anticipate how different IdPs may handle this scenario. The solution is to open a case with Quickbase Technical Support and request that the “Signed Authn Requests” option be disabled.Preparing for Automations End of Support on June 30, 2022
Workflow automation has taken many forms in Quickbase over the years. It could be a simple email notification, a dynamic form rule, or even a complex script triggered by a webhook. But one thing that’s clear is that workflow automation is only going to increase in importance for customers and use cases of all kinds. To meet those evolving requirements, we have spent the last year growing and improving the workflow automation capabilities of our powerful new Pipelines technology. Now, as we continue to look toward the future, we must also evaluate the role of older and less flexible features like Quickbase Automations. That’s why we will be retiring Quickbase Automations in favor of Pipelines. On June 30, 2022, Automations will reach End of Support. What End of Support means for you The next step in retiring Automations will come on June 30, 2022, when the feature will reach End of Support. At that time, you will no longer be able to create new automations. This also means that the Quickbase Technical Support team will not be able to assist with the Automations feature after June 30, 2022. Existing automations will continue to be editable, and they will continue to run until Automations reaches End of Life. Read on to learn about the benefits of using Pipelines instead of Automations, and how you can prepare for Automations retirement by migrating your existing automations. Improving your workflow using Pipelines We have been continuously adding new capabilities and tools that will make it easy for you to migrate your workflow automations to our newer and more powerful Pipelines technology. Not only will this ensure that you don’t experience any disruption to your business or your processes, but it also opens the door to new workflow ideas that can connect across multiple systems. Pipelines supports all Automations features – Pipelines now supports all the features you’ve been leveraging within Automations, including the ability to query the previous value of a field. Pipelines enables more sophisticated logic than Automations – Pipelines supports more powerful business logic than Automations, including branching and looping, as well as parsing text. Pipelines gives you the ability to scale workflow across systems – In addition to orchestrating workflow within your Quickbase ecosystem, Pipelines includes point-and-click integration with over 30 products including Outlook, Slack, and Sharepoint. We are committed to supporting every Automations use case. That’s why all Quickbase customers get unlimited use of Quickbase-to-Quickbase Pipelines included with their service plan at no additional cost. Focus areas for improving Pipelines We’ve gotten feedback from many of you on Pipelines, about what’s going well and where we have opportunity to improve. Thank you for taking the time to share your thoughts with us. Getting this perspective is essential to help us evolve our product and make sure we are serving this community well. There are three main areas we are focusing on to further support you as you migrate from Automations: Ease of use – We are working on improvements to make it faster and more intuitive to build pipelines. For example, in the January 2022 release we are making our builder wizard generally available. Using the wizard, the user first chooses which steps to include. Then, they are directed to the pipelines designer page where they fill in the details for how each step should work. We have also extended our Pipelines educational resources in Quickbase University, with the release of our new Pipelines Builder certification exam. Performance – In December 2021, we rolled out the new “Blaze” engine to offer better reliability, performance, and efficiency for Pipelines. Compared to November 2020, usage of our Pipelines capability has multiplied by more than 71 times, and the Blaze engine helps support that exponential increase in workload. It also lays the foundation for the next round of exponential growth in integration and automation use-cases which companies are looking to create with Quickbase Pipelines. We’ve seen pipelines run 30 times faster on average since releasing the Blaze engine. Governance – We are making major investments to make it easier to manage your pipelines at scale. Account administrators will be able to set access to Pipelines channels by individual user, or by user group. Pipelines builders will also be notified when one of their pipelines encounters an error. And finally, app builders will be able to see a list of pipelines connected to their app. Each of these features will be available in the first half of 2022, before we reach the End of Support date for Automations. Preparing to migrate There are three steps you can take to prepare for your migration from Automations to Pipelines: Make sure you have access to Pipelines – Some of you are app builders who have built automations but have not had a chance to start working with Pipelines. It’s worthwhile to check the top-left of your Quickbase view to make sure you have Pipelines access set up. If you do not see the Pipelines tab, you’ll need to contact one of your account admins to get access. Create new workflow automations using Pipelines instead of Automations – Since Automations will not be supported starting on June 30, 2022, this is the perfect time to stop creating new automations and creating pipelines instead. We have many resources available to bring you up to speed. (Check out our list on the community.) Begin migrating your existing automations to Pipelines - We’ve developed a simple migration tool you can use to create a corresponding pipeline for each of your automations, which you can do in just a few clicks. We have been improving the migration tool over the past few months, and it is now ready to migrate virtually any automation. (Learn more about using the migration tool in our help article.) Timeline Over the several months, we will be following our standard feature retirement lifecycle, and taking several steps along the way to retire the Quickbase Automations feature. Timing Retirement Phase Description June 22, 2021 End of Sale We will focus on making sure that all our customers have the information and resources they need to successfully plan for the migration of their Automations to Pipelines. Even though the Automations feature will still be available to existing customers, we encourage customers to begin using Pipelines to implement new workflow automation ideas moving forward. June 30, 2022 End of Support Your existing Automations will continue to run without interruption, but you will no longer be able to create new Automations or get assistance with the building and configuration of Automations from Quickbase staff. During this time, we encourage you to migrate any remaining Automations to Pipelines at the earliest possible opportunity. TBD End of Life Automations is officially retired. This means that it is fully removed from our product, and remaining Automations will cease to function. Learn more Learn more about using the migration tool in our help article. Take the Getting Started with Pipelines course in Quickbase University. Take the Pipelines Builder certification exam. Browse all the Pipelines resources available on the community. Explore the 30+ point-and-click integration channels available for Pipelines. Learn more about Quickbase’s process for retiring product features.
Formula URL button - save and redirect
Hi there I?ve created a form accessible to ?everyone on the internet? for our clients to submit service requests. I added ?&ifv=20? to the url to hide the qb branding. However, doing this causes the save button to become hidden. I created a formula url button that will save it using this javascript I found on the forum: var text URL = "javascript:void(DoSaveAdd())";var Text Image = "<a id='saveButton' class='Vibrant Success' onclick='DoSaveAdd()' href='#'>Submit</a>";"<b href =" & $URL &">" & $Image & "</b>" My problem now is how do I get the page to redirect after the form is saved. Here?s a link to the form, you can try it and see what happens. https://sparkav.quickbase.com/db/bnzwm7ykp?a=nwr&ifv=20 I'd like it to redirect to an external webpage. If that is not natively possible than I'd like it to redirect to a rich text page I've created in quickbase. Any help with this would be greatly appreciated! Thanks, Elisha
Send SMS Text Messages with Pipelines and Twilio
Send SMS Text Messages with Pipelines and Twilio Twilio is a service used to automate SMS text messaging. Including Twilio within your Quickbase ecosystem can be a huge value gain, adding efficiency to internal processes, like alerting employees out in the field or providing transparency to your customers with real-time updates. In this blog, I'll be focusing on a Work Order use case where we provide the customer with real-time status updates throughout the lifecycle of the Work Order. Getting Started First things first, login to your Twilio account and make sure you have your Account SID and Authentication token ready to go in order to authenticate your Twilio channel. From your Twilio profile, click on Settings → General. The API Credentials dialog will display the following... Once you have the above information go to your pipeline, locate the Twilio channel, and copy/paste the Account SID and Auth Token accordingly. For a more detailed breakdown of authenticating to your Twilio account, click here. The Use Case As I mentioned above for my use case I'll be using the example of a Work Order. We will be sending status updates to the customer as the order is received, the technician is on his way, and when the technician has arrived. In this example, I have two tables, 1 for my Work Orders and a related child table for Status Updates. Below is a breakdown of the relationship and the fields we'll be using in the pipeline. The idea here is everytime we add a new status update it will trigger Twilio to send an SMS text message to the phone number of the contact on our Work Order with any additional details we provide. The Pipeline Step A: Quickbase record created(trigger) 1. Locate the Create record trigger and drag it into Step A. 2. Select your Status updates table from the table dropdown. 3. Specify fields needed for subsequent steps. e.g. Status, Contact Name, Contact Phone Number, Order #, Details etc. Step B: Send Message (Twilio Action) 1. Locate the Send Message Action within the Twilio channel and drag it into Step B below the Trigger in Step A. 2. Authenticate to your Twilio account and select the number you wish to use for these messages. 3. Drag the Phone Number from Step A into the corresponding "To" field. 4. In the body create your own message using a combination of your own words and the fields from Step A. e.g. Hi {{a.work_order_contact_name}}. Your status for Order#{{a.work_order_order}} has changed to {{a.status}}. {{a.details}} That's it! The pipeline is complete! Now to see the finished product! Conclusion After reading this you should now be ready to create your first pipeline utilizing the Twilio channel! It's a quick and easy way to augment your Quickbase ecosystem by gaining more efficiency and transparency throughout your many workflows! Drop a comment and let us know other ways you plan on using the Twilio channel!Upcoming Changes to JavaScript in Quickbase
If you’ve ever used JavaScript to modify UI or enable a non-native workflow in a Quickbase app, this post is for you. We know that adding custom code to an application can be a valuable way to extend Quickbase. However, we need to provide this capability in a secure and supportable way. To that end, Quickbase provides the ability to use custom code in code pages. On the other hand, we also see builders inserting custom code into places it was never intended to be used. To improve the security and stability of the platform, we are changing the way Quickbase handles custom code. Specifically, we are changing how the platform handles JavaScript and unsupported HTML tags in places other than code pages. Code pages are where custom code has always been supported, and we encourage app builders to insert it there. We will roll out these changes throughout 2021. This post will cover the background on where custom code is supported in Quickbase, and why it’s important for us to make a change. You can also find details about our plan below, and how that impacts you. Table of Contents Background Upcoming Changes Product Alternatives Next Steps FAQ Background For years, Quickbase builders have inserted JavaScript outside of code pages. This has been done to customize the UI or to automate workflow (such as reloading the current page). Yet custom code such as JavaScript was never intended to be used in a Quickbase app, except in code pages. Builders have shared many solutions like this on our community forum. You might see them called "Image OnLoad" or "Branding OnLoad". Because the added JavaScript code cannot be sanitized by Quickbase, it could open a security vulnerability that a sophisticated, malicious, builder could take advantage of. “Sanitizing” is simply making sure that an input into a field is what the software intended. For example, to sanitize a field that says “Image URL”, we would ensure it only accepts a format like https://mywebsite.com/images/banner.png and that it only contains secure content. None of the code within a code page can access the native Quickbase document object model (DOM). When you write custom code such as JavaScript in a code page, you are creating a new web page from scratch. This is why it is more secure to restrict JavaScript to being used only in a code page The Quickbase platform includes many security measures which protect you against the risks mentioned above. For example, when you create a new app, any API call pointed at that app must include an application token. We have put in place policies to control cross-origin resource sharing (CORS). And we allow realm admins to restrict what type of content may be embedded as an iFrame within their apps. But the work of building a platform with world-class, enterprise grade security never stops. Our software engineers and system architects are always searching for opportunities to improve. Changing how JavaScript is handled in Quickbase apps is the next step in that journey. Besides this security issue, it's impossible for us to test inserted JavaScript as we make changes to the Quickbase platform. A routine upgrade to an open source library, a change to styling, or to the DOM may cause these custom solutions to break without warning. As we progress with projects like the UI Refresh in 2021 and beyond, these kinds of changes will become more frequent. In order to move the platform forward in a safe, secure, and sustainable way, we must close the loopholes that allow builders to insert unsanitized custom code into their apps. Upcoming Changes There are three areas of the product that need to have the loophole closed. We will close one area at a time, every two months starting in April 2021. Rich Text Fields, where customers could unintentionally allow end users to insert JavaScript. This area was closed in the April 2021 release. Note: This does not include Formula-Rich Text fields. Custom Branding, where customers typically insert JavaScript to modify the UI in non-native ways. This area was closed in the June 2021 release. Formula Fields, where customers can write scripts to automate workflows. Examples of these include cascading deletes and executing multiple actions when a user presses a button. This area will be closed in the August 2021 release. This includes Formula-Rich Text fields. When an area is closed, builders will no longer be able to insert new JavaScript or edit the JavaScript that has been inserted into the area. With these series of changes, we will not remove or modify any existing custom code. We will not intentionally break any existing solutions that leverage these techniques. But a change to styling, a change to the DOM, or an update to a technical library could cause a solution to unintentionally break without warning. And, if a solution breaks for one of these reasons after the area has been closed, builders will not be able to edit the JavaScript to fix it. After we close each loophole, builders will no longer be able to insert or update JavaScript in that part of their apps. For example, imagine you have a formula that contains JavaScript. You need to update the formula, so you open the field properties. In that case, we would pop up a message warning that the field contains unsupported content. If you click Save without removing the JavaScript, you will see an error message preventing the save. You may hit cancel at that point, to back out and keep the previous configuration of your field. We encourage you to continue extending your ecosystem of apps using custom code. You can use custom code such as JavaScript in code pages, even after we close all the loopholes above. NOTE: The vast majority of custom code that's inserted into Quickbase apps outside of code pages is JavaScript code. However, the product changes above will not just restrict where JavaScript can be used. Those restrictions will apply to all custom code that is unsupported outside of code pages. The only custom code that may be used outside of code pages is: Simple HTML tags such as "a", "div", and "img". (See a complete list of supported HTML tags) Any native HTML attributes for those tags. (Such as the "width" and "height" attributes of the img tag) CSS style code which is included in-line, as part of one of the supported HTML tags above As a reminder, iFrame HTML tags are not supported outside of code pages and they will be affected by the product changes above. Product Alternatives Many agile companies extend their Quickbase apps today using custom code. This is a crucial tool for flexing and adapting to a fast-paced business environment. The intended workflow for Quickbase to interact with custom code is by having a formula-url or formula-rich text field as a button or link. Clicking on one of these would open a new browser tab, or redirect the current tab, to the code page. Custom HTML, CSS and JavaScript can be included in this code page. If desired, the page can close itself and redirect to the original page. For example, see the animation below: We will also work to make this even easier in the future. Over time, we will address the majority of extensibility needs in a few ways: Our ongoing product initiatives have an increased focus on customization and power natively. We know will not be able to build a native setting, switch or toggle for every possibility. Yet we conduct research and make data-informed decisions on where more flexibility makes sense. We will continue to absorb small items into future product iterations that customers need so custom code isn’t needed. Examples of this include, but are not limited to: Ability to use Now to get the live time a formula-url was pressed, rather than when the first page loaded New formula functions like UserRoles() and NameOfMonth() More control over the behavior of formula-urls Allow app builders to use JavaScript in certain areas outside of Code Pages. These would not allow arbitrary code to be inserted. Instead, they would support specific methods of extending a Quickbase app with custom code. For example, let's consider the new dashboards in beta as of February 2021. These new dashboards allow app builders to create filters which apply to all reports and charts on the page. We could allow a developer to create a custom chart type, which connects to the dashboard filter. So when an app user clicks that filter, all the reports and charts on the dashboard would update - including the custom-coded charts. This would allow builders to create their own chart, and have it behave natively and seamlessly for their users. We have many plans in this area. While this is not an overnight deliverable, we are confident in the research we have done and our roadmap to deliver on this promise. Programming languages like JavaScript are powerful because they are open-ended. You can use JavaScript to solve virtually any problem if you have the time and technical know-how. But Quickbase is a no-code platform. Quickbase is powerful because of how fast it allows you to build and update apps, deliver value and unlock insights within your data. So we will always focus on accelerating that speed and ease of use. We do not intend for Quickbase to become a full-fledged integrated development environment (IDE). Next Steps First, we want to be as transparent as possible, so app builders are aware of any risks in their applications. To that end, builders will begin seeing a warning in areas that have unsupported content in the near future. This will not prohibit changes to these areas of the platform. Are you already thinking about some of your apps which use these JavaScript techniques? If so, please start planning how you can migrate to supported solutions. We have been logging Quickbase apps that contain unsupported custom code. Those logs are only able to cover apps where you've updated the app’s structure recently. So if you have an app you're unsure about, you can update the properties of any field or table to get it added to the logs. That way, if that app does contain JavaScript or other types of unsupported custom code, it will appear in the logs the following day. On February 11th, we'll send an email inviting account admins to a Quickbase app so you can see where inserted JavaScript is being used. If your account admin does not receive that email, it means that our logs do not show any inserted JavaScript in your account. Review the list of FAQs below. If you still have questions or need help, don’t hesitate to reach out to our Care team by submitting a ticket. We're happy to help identify alternative solutions. However, please note that we will not be able to interpret or troubleshoot custom code. If you find yourself in need of more hands-on assistance, we recommend engaging with one of our QSPs, whom we can help you connect with. FAQ What is JavaScript Insertion? JavaScript Insertion occurs when custom JavaScript code is added to any part of a Quickbase app other than a code page. Some examples include formula fields, rich text fields, and custom branding. While officially not supported, these techniques are used to more deeply customize an app’s UI or workflow. While this has never been officially supported, the platform was not explicitly blocking this as it should have been. As we have added features to the platform over the years, many of the reasons why these techniques were used have become obsolete. What is changing with regards to JavaScript Insertion? We will begin restricting app builders from inserting JavaScript in formula fields, app branding, and rich text fields. Builders will no longer be able to insert new JavaScript code in those areas. We will also block edits to any existing JavaScript in those same places. These areas were never intended to allow for JavaScript insertion. You can still insert JavaScript in a Code Page, which is the appropriate place in a Quickbase application. Will these changes only affect inserted JavaScript code? The vast majority of custom code that's inserted into Quickbase apps outside of code pages is JavaScript code. However, the product changes above will not just restrict where JavaScript can be used. Those restrictions will apply to all custom code that is unsupported outside of code pages. The only custom code that may be used outside of code pages is: Simple HTML tags such as "a", "div", and "img". (See a complete list of supported HTML tags) Any native HTML attributes for those tags. (Such as the "width" and "height" attributes of the img tag) CSS style code which is included in-line, as part of one of the supported HTML tags above As a reminder, iFrame HTML tags are not supported outside of code pages and they will be affected by the product changes above. When will these changes take place? Throughout a series of releases in 2021. After the April 2021 release, users will no longer be able to insert JavaScript into Rich text fields. After the June 2021 release, users will no longer be able to insert JavaScript into Custom Branding. After the August 2021 release, users will no longer be able to insert JavaScript into Formula Fields. Why do we need to make these changes? Custom JavaScript inserted into these areas is not sanitized by Quickbase. This opens the platform up to potential attacks from malicious users, to modify pages or gain access to protected data. Such custom code is also impossible for Quickbase to test. This means routine changes to the platform could (and do) cause a solution to break without warning. Closing these loopholes allows us to provide a more supportable, enterprise-grade platform. It also enables our support resources to triage and troubleshoot more effectively. How are we informing customers of this change? On February 11, 2021, we will email Account Admins who will be affected by this change. The email will include a link to a Quickbase app which will help you locate inserted JavaScript in your apps. We will email those Account Admins before we make each of the product changes above. Those changes will take affect with our product releases in April 2021, June 2021, and August 2021. Application Managers will also see warnings in apps that include inserted JavaScript. For example, a message will appear if you edit the properties of a formula that includes inserted JavaScript. What will happen with existing JavaScript solutions? We will not be making any changes to existing objects that contain inserted JavaScript at this time, or during any of the releases mentioned above. That means that solutions that leverage inserted JavaScript should continue to work as they were designed. However, builders will not be able to save changes to these objects after their respective release. After the April 2021 release, you will not be able to make changes to JavaScript within Rich Text fields. After the June 2021 release, you will not be able to make changes to JavaScript within Branding. After the August 2021 release you will not be able to make changes to JavaScript within Formula fields. As always, these solutions might break as a result of a routine change we make to the Quickbase platform. For example, upgrading a technical library, or changing either our styling or our Document Object Model (DOM) could cause inserted JavaScript to stop working. What will happen if a builder attempts to save changes to an object with inserted JavaScript? After we close each loophole, builders will no longer be able to insert or update JavaScript in that part of their apps. For example, imagine you have a formula that contains JavaScript. You need to update the formula, so you open the field properties. In that case, we would pop up a message warning that the field contains unsupported content. If you click Save without removing the JavaScript, you will see an error message preventing the save. You may hit cancel at that point, to back out and keep the previous configuration of your field. What will happen if I copy an app with inserted JavaScript? Customers should be able to copy applications with unsupported JavaScript. The inserted JavaScript will carry over to the copied app. As with any inserted JavaScript, after we close down the area it is inserted in, builders will not be able to edit it. Should I remove all inserted JavaScript from my Quickbase apps? We are not removing or modifying any existing inserted JavaScript. You can continue to use your apps that contain inserted JavaScript. But, while we are not intentionally breaking any solutions that rely on inserted JavaScript, these solutions could break as a result of a routine change to the platform, like a change to styling, an upgrade to technical libraries, or a change to the Document Object Model (DOM). As we progress with the UI Refresh Initiative, these changes will become more frequent, increasing the chances that your apps could break. If you want to avoid that risk, you should explore alternative, supported solutions to the problems you’re solving with inserted JavaScript. What if I need help? If you’re still not clear on exactly what is changing, or have a specific question about your account, you can always submit a support case to our Care team. Also, our Quickbase Solution Providers (QSPs) are a network of professional services firms that you can contract with to help you plan for and execute any changes to your apps that you might deem necessary as a result of this announcement. They can help you identify and implement alternative, supported solutions to the problems you currently solve with inserted JavaScript. If you are working with a QSP already, you can follow up with that partner or find a potential partner here. We also have a list of partners who are providing services offerings to specifically handle JavaScript issues. If you would like a referral to a partner or potential partners, submit a support case, and a support representative can provide this for you. Can builders still insert JavaScript into code pages? Yes, users are encouraged to use code pages to leverage custom code for their Quickbase applications. These code pages should be used standalone, rather than attempted to be “injected” into a Quickbase page. What if I need help identifying my inserted JavaScript? The first place to look is the Inserted JavaScript Usage app. This is a Quickbase app that lists where inserted JavaScript is used in your apps. It includes details such as Field ID for formulas that include inserted JavaScript. On February 11, 2021, we will email a link to this app to Account Administrators. We will send this email only to accounts we've detected are using inserted JavaScript. Not sure whether a specific app includes inserted Javascript? You can check this by opening the app in question, then making any schema change. For instance, you could add a new field or update the properties of an existing field. Then, you can check the Usage app one day later. We update the Usage app daily. So if the app in question still does not appear in the Usage app then you do not need to take further action. Will Copy Master and Details buttons be affected? No, as long as you are using your Copy Master and Details button as it was originally generated (i.e. no changes were made to the formula) it should not be affected by these changes. If you have Copy Master and Details buttons, you may have received a warning in your application about the presence of unsupported content. To be clear, after the August release, you will not be able to edit these formulas. However, unlike other formulas that contain JavaScript, these buttons will continue to work as designed and do not need to be replaced with alternative solutions.
