Resource Icons
Latest Highlights
Check Out The Latest in The Qrew
1 MIN READ
Hi Qrew,
While there are no Qrew Meetups this week, this is an important week for the Qrew, as we'll be opening up registration for Empower26! Be on the look out for more details for Call...
2 days ago
1 MIN READ
If a quick summary is what you need, in under 3 minutes I will walk you through the most recent updates to Quickbase, right here:
Highlights include:
New getRo...
5 days ago
3 MIN READ
When you talk to Mark, you can sense two things immediately:
he’s been using Quickbase for a very long time
and he’s still having a blast.
As the founder and Principal Engineer of Your Qui...
5 days agoThe Content Feed
Feed
Denying ticket does not move it to "Denied" stage in pipeline.
I created a Kanban board as my pipeline for new ticket request that come in when requestors need help with something. They rest of the automation works well, however for some reason I when opening a ticket and denying it, it does not move to the "Denied" stage in the pipeline, but rather it stays in the "Requests Received" stage. I would appreciate assistance resolving this. Thank you.Want the Approve/Deny buttons to disappear once ticket is approved.
I built a ticketing system for our department so we can receive requests from employees for assistance they may need. Once my manager reviews the ticket and approves and assigns it to a team member for them to work on it, I want the Approve/Deny buttons to disappear on the Internal Ticket Review Form's "Edit" view we see when we click on the ticket to open it once the ticket has been approved. I also don’t want the Approve/Deny instructional text to show after that either. How can I do this? Thank you.Creating a 'foreach' style loop in pipelines
Is there a way to do create a loop in Pipelines that runs a set number of times? For example, I want to run it x times based on user input: When a record is updated, it will make X copies of it based on a "clone quantity" field in the updated record. Thanks! ------------------------------ Matt Makris ------------------------------
SAML Public Authentication Certificate for Signed Authn Requests (Updated 11/4/25)
November 4th, 2025 Update: We have updated this article with the new Quickbase SAML Zip File. Below in this article, you will find both the current Zip File which will expire on November 25th, 2025 and the new Zip File which will expire on October 30th, 2026. 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. New Certificate (Expires October 30th, 2026): QB_SAML_Exp10-30-2026.zip Current 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.Unlock Document Insights with AI Actions: Summarizing a 10-K Filing in Pipelines
About a week ago, I showed how AI Actions can extract key details from emails and structure them for use in Pipelines. Today, let’s take it a step further — using AI Actions to analyze entire documents. And not just any document, but something a little more substantial — a 10-K filing. Why a 10-K? A company’s annual 10-K report is a goldmine of information: performance trends, risk factors, and management insights. But let’s be honest — few people have the time (or patience) to read through hundreds of pages. With AI Actions, Quickbase users can upload a 10-K file and automatically generate a concise, executive-ready summary — right inside Quickbase. No APIs, no custom models. Just a pipeline. The Pipeline Flow Here’s how the process looks end-to-end: Trigger: A new 10-K document is uploaded to a Quickbase table (e.g., Filings). AI Action: The file is securely sent to the AI with a rich financial analysis prompt. Result: The AI returns a summary recorded in a rich text field - ready to be shared in your app. Watch the demo here. Example Pipeline and 10-K Amazon's 10-K - https://ir.aboutamazon.com/sec-filings/default.aspx Pipeline YAML: # Dcoument Summary # # Account slugs: # - quickbase[REDACTED]: Realm Default Account <None> --- - META: name: Dcoument Summary enabled: false - TRIGGER quickbase[REDACTED] record on_create -> a: inputs-meta: export_fields: '"10-K File, Summary" <6, 7>' table: '"AI Actions - Georgi Peev: 10-K" <REDACTED>' name: Document uploaded - ACTION qb-ai-actions custom_action create -> b: inputs: file_url: '{{a.n10_k_file.file_transfer_handle}}' system_message: "**Role:**\n\nYou are an elite financial analyst specializing\ \ in evaluating the financial health, performance, and outlook of Fortune\ \ 500 companies. You analyze company financial statements, ratios, and macroeconomic\ \ factors to produce clear, executive-ready insights.\n\n**Tone & Personality:**\n\ \nYou are professional, analytical, and articulate. You communicate findings\ \ in a clear, structured format that's easy to read in Quickbase. Avoid excessive\ \ jargon \u2014 your goal is to make complex financial information understandable\ \ and actionable.\n\n**Core Capabilities:**\n\nAnalyze **income statements**,\ \ **balance sheets**, and **cash flows**\n* Evaluate **profitability**, **liquidity**,\ \ **leverage**, and **efficiency ratios**\n* Perform **trend and comparative\ \ analysis** versus peers\n* Assess **valuation metrics**, **risk factors**,\ \ and **growth outlooks**\n* Integrate **macroeconomic context** into your\ \ conclusions\n* Generate **forward-looking insights** backed by quantitative\ \ reasoning\n---\n\n**Formatting & Output Rules (Quickbase-Friendly)**\n\n\ Your output **must be formatted in HTML**, using the following conventions\ \ to ensure clear line breaks and sectioning: \n\nUse `<h2>` for major sections\ \ (e.g., Executive Summary, Outlook).\nUse `<h3>` for subsections (e.g., Overview,\ \ Key Ratios).\nUse `<p>` for paragraphs.\nUse `<ul>` and `<li>` for bullet\ \ lists.\nUse `<strong>` for bold metrics or key figures.\nAdd `<br>` only\ \ when you need an extra visual line break inside a section.\nDo **not** use\ \ Markdown (`##`, `-`, `**`, etc.).\nKeep output readable and well-spaced\ \ \u2014 each section should be visually distinct.\nEnd with a short concluding\ \ paragraph summarizing the company's outlook." user_message: Process the file provided. name: Process document - a<>ACTION quickbase record update -> c: inputs: summary: '{{b.output_text}}' name: Save summary ... The AI Prompt Here’s the full system prompt passed to AI Actions — formatted for clear output inside a Quickbase rich text field. **Role:** You are an elite financial analyst specializing in evaluating the financial health, performance, and outlook of Fortune 500 companies. You analyze company financial statements, ratios, and macroeconomic factors to produce clear, executive-ready insights. **Tone & Personality:** You are professional, analytical, and articulate. You communicate findings in a clear, structured format that's easy to read in Quickbase. Avoid excessive jargon — your goal is to make complex financial information understandable and actionable. **Core Capabilities:** Analyze **income statements**, **balance sheets**, and **cash flows** * Evaluate **profitability**, **liquidity**, **leverage**, and **efficiency ratios** * Perform **trend and comparative analysis** versus peers * Assess **valuation metrics**, **risk factors**, and **growth outlooks** * Integrate **macroeconomic context** into your conclusions * Generate **forward-looking insights** backed by quantitative reasoning --- **Formatting & Output Rules (Quickbase-Friendly)** Your output **must be formatted in HTML**, using the following conventions to ensure clear line breaks and sectioning: Use `<h2>` for major sections (e.g., Executive Summary, Outlook). Use `<h3>` for subsections (e.g., Overview, Key Ratios). Use `<p>` for paragraphs. Use `<ul>` and `<li>` for bullet lists. Use `<strong>` for bold metrics or key figures. Add `<br>` only when you need an extra visual line break inside a section. Do **not** use Markdown (`##`, `-`, `**`, etc.). Keep output readable and well-spaced — each section should be visually distinct. End with a short concluding paragraph summarizing the company's outlook. File Tips To stay within the 2 MB file limit: Upload just the relevant sections of documents. Compress PDFs or use text-based files. Avoid exhibits, charts, or large tables that aren’t text-based. Why This Matters This example shows how AI Actions can do more than summarize — it can transform complex corporate filings into clear insights your team can act on. Whether you’re building dashboards for operations teams or automating document reviews, AI Actions lets you bring analytical intelligence directly into your workflows. Conclusion AI Actions isn’t just about connecting to AI — it’s about empowering Quickbase users to extract real business value from their data and documents. Start small: upload a company’s 10-K, run your pipeline, and see how much time your team can save. You’ll never look at financial reports the same way again. Stay tuned for my next blogpost where I will be creating a weekly summary from a Quickbase report.The Qrew Monday Update
Hi Qrew, While there are no Qrew Meetups this week, this is an important week for the Qrew, as we'll be opening up registration for Empower26! Be on the look out for more details for Call for Speakers and registration information. Office Hours Quickbase Office Hours Sam Trachy is back! Monday–Friday @ 1 PM EDT FastField Office Hours Monday, Wednesday, Friday @ 2 PM EDT Our next Qrew meetups: App Builders Qrew Meetup Nov 11 @ 12pm EDT Pipelines Qrew Meetup Nov 19 @ 12pm EDT. Upcoming Fundamentals Trainings: Explore an App Nov 3 @ 11:00am EST Begin to Build Nov 4 @ 11:00am EST Import Data Nov 10 @ 11:00am EST Resources from the Qrew... This Month's Qrew Calendar Sam Trachy’s Office Hour: M-F @ 1pm ET *He's back!! FastField Office Hours: M,W,F @ 2pm ET Quickbase University The Qrew Discussions Page Customer-led Quickbase Discord Thanks for being part of the Qrew and we hope to see you at office hours!
Use AI to create a field based on another text field
Is it possible to use AI to create a field "Category" based on another text field "Description." The field description is of-course is verbose and all over the place. But technically LLM should be able to create a succinct 'Category' field for me by parsing the actual topic of discussion captured in the description field. Is this possible within Quickbase?
Modifying an existing app for unusual reporting needs
Hello all! I started toask this in a subsequent question yesterday (we need the Qrew posts to be editable so we can add to an original post rather than reply/have it potentially get lost!). Thanks to the legend Mark Schnier for some help on a specific formula. Now I'm trying to wrap my head around a bigger challenge. The app I'm fixing has some (what I consider) unusual reporting requirements. We have Clients, who have Cases, and our team of Users have Interactions with the Clients about the Cases. Presently, the app is structured with only two tables for those three things -- "Client/Case Files", and "Interactions". So question #1 is -- as I add in a 3rd table, I'd love any words of wisdom about correcting any legacy data into the 3-table format. Or do I just let it go and course-correct forward? Question 2 is around building logic so as we can get the nuanced reporting we need. Each Quarter, we have to report out on 1. How many total Clients were served, and 2. How many Clients were NEW that quarter. Then, at the beginning of a new fiscal year, all legacy clients are counted NEW again. So each time a legacy Client presents for the first time in a new Fiscal Year, I need to be able to report out when they're "new". That could happen any time within the Fiscal Year, and I'm really struggling to wrap my brain around how to build that specifically. Lastly - and the form field that Mark helped me build, which I'll need to wrap my head around within the context above -- is that we need to report out the demographics on those. As those demographics are generally client-reported to us, they can change -- so I need a mechanism to ensure we're 1) capturing that info, 2) updating that info when the person needs to be reported out again new, and 3) in particular with the demographic of what "age range" someone is in, those things of course change. So to that, ideally I'd have a way to also capture it as it is, in one particular point in time -- so that if we ever were to need to audit a past report, we can see how the reporting was then; and be able to also pull the present reporting out as it is today. Any help is welcome! I feel like the entire conundrum sort of bends my brain in half, and I don't know if I'm just being a dunce, or if this is truly just unusual reporting parameters! I hope this makes sense - and thanks in advance for any guidance!November 19th 2025 Qrew Meetup Event
Portland Qrew is meeting Wednesday, November, 19th 3PM PST at Harder Mechanical Contractors and also on Teams. This month we'll talk about current projects, new changes and challenges and our favorite dressing. Anyone can show off work and cheer each other on. We ask attendees to bring problems to solve and then work together to provide a solution. Anyone willing to share is welcome to have a problem solved by a team of very nice people who all love helping. Afterwards I suspect we will go out somewhere and welcome recommendations. If you would like to join remotely email jharrison@harder.com directly and he will send you a Teams invitation.
