Resource Icons
![](https://i.imgur.com/Otf8WJF.png")
Latest Highlights
Check Out The Latest in The Qrew
1 MIN READ
July 2026
Regional Meetups
July 15 Boston Qrew Meetup July 30 Atlanta Qrew Meetup July 16 Denver Qrew Meetup July 22 Portland Qrew Meet...
8 months ago
Quickbase trainer (and occasional Bob Ross impersonator) RobHenderson shows us one way to approach complex app relationships.
Want to explo...
23 days ago
At Empower, we announced that grid reports are generally available in Quickbase. Grid reports bring that familiar, spreadsheet-like experience into Quickbase, so users can work with operational data ...
26 days agoThe Content Feed
Feed
How to add Tabs (Pages) to only a specific section of a form?
Hi everyone, I’m trying to organize a form using Tabs (Pages), but I’m running into some confusion with how Quickbase handles them.Previously, I was able to add new sections below existing ones without issues. However, when I try to add a new Page (Tab), Quickbase automatically moves all my existing fields into Page 1 and puts the new fields on Page 2. The tabs also always appear at the very top of the form. What I actually want is to have tabs (or a tab-like experience) applied to only a specific section lower down in the form, without wrapping the entire form into multiple pages. Is there a way to achieve this? Or what is the recommended approach — using multiple Pages, Sections with rules, or a completely different method? Any advice or best practices would be greatly appreciated! Thanks in advance.
URL Add Related Form (But popup like embedded Reports)
I am trying to make a URL Button to add a child record in a form Example: URLRoot() & "db/" & DBID & "?a=API_GenAddRecordForm&_fid_13=" & ToText([Record ID#])& "&dfid=10&popup=1" I also tried: URLRoot() & "db/" & DBID & "?a=API_GenAddRecordForm&_fid_13=" & [Record ID#] & "&target=popup&popupwidth=500&popupheight=400" I also tried these checking In Same Page, In New Window, And In Pop Up.but the button does not pop up like the embedded report. is it possible to make a button that works this way on PC and Mobile as it does in the Report button Link?Improving pipeline resilience: field rename handling and stable step identification in Pipelines
Quickbase applications and workflows evolve, fields get renamed and pipelines get reorganized. These are routine activities — but until now, both could affect the accuracy of a pipeline configuration in ways that were not always immediately visible, requiring manual intervention to identify and correct. Two recent updates to Quickbase Pipelines address this directly: field renames in Quickbase are now automatically detected and applied, and step identifiers are now permanently stable regardless of how a pipeline is reorganized. This post describes each change, the mechanism behind it, and the practical implications for pipeline reliability and troubleshooting. Background As pipelines grow in complexity, it becomes common to reference the output of one step in the logic of another — passing a value forward, applying a transformation, or building conditional logic around a result. These references are written as Jinja expressions, and they depend on two things staying consistent: the name of the field being referenced, and the identifier of the step whose output is being used. Both of these could previously change as a result of ordinary activity — renaming a field in Quickbase, or reorganizing steps in the pipeline designer — without any corresponding update to the expressions that depended on them. When a field was renamed in Quickbase, Pipelines had no mechanism to detect the change. Any step mapping or Jinja expression using the previous field name would continue to reference a name that no longer existed, producing incorrect output or failing without a clear indication of the cause. When steps were reordered, a similar problem occurred at the pipeline level. Step identifiers were alphabetical and positional — reassigned to maintain sequential order whenever the pipeline was reorganized. An expression that correctly referenced a step before a reorganization could, afterward, point to an entirely different step or resolve to nothing at all. In both cases, the expressions appeared intact in the designer while no longer functioning as intended. Stable field references: automatic rename handling When a field is renamed in Quickbase, Pipelines detects the change at the next refresh and applies two updates together: Step mappings — any step that mapped a value to the renamed field continues to do so under the new name, with the configured value preserved. Jinja template references — standard {{ refID.field_name }} expressions referencing the renamed field, across every step in the pipeline, are rewritten to use the new name. When the update takes effect The update is applied the next time Pipelines re-reads a step's fields from Quickbase. This occurs in three situations: Refresh Schemas — re-reads all steps in the pipeline simultaneously. Recommended after multiple field changes in Quickbase, or to confirm the final state of a pipeline following rename activity. Single step refresh — re-reads only the selected step. If a rename is detected, Jinja references to that field are updated across all steps in the pipeline, not just the one being refreshed. Certain step edits — adding or changing a field via the field selector, or modifying a step's options, triggers an automatic schema re-read as part of saving. Any rename present at that point is applied as part of the same operation. Pipelines continue to execute correctly between a rename and the subsequent refresh — the old field name remains valid until a refresh occurs. No configuration is lost in the interim. Scope Automatic rename detection applies to standard Jinja field references ({{ redID.field_name }}) and step mappings. References embedded in custom Jinja expressions — logic or transformations written manually — are not automatically updated and should be reviewed and corrected manually after a rename. This behavior applies to Quickbase fields only; field renames in other connected channels may still require manual reconfiguration. Stable step references: Reference ID and Step Number Step identification now separates into two distinct identifiers, each with a defined and exclusive purpose. Reference ID (Ref ID) is a permanent identifier assigned to a step at creation. It is not modified by reordering, insertion, or deletion of surrounding steps, and is never reassigned after a step is removed. The Ref ID is the identifier to use in Jinja expressions, and the one that appears in activity logs, error notifications, and field usage views. Ref IDs use an extended alphabetic format: aa, ab, ac… zz. Step Number is a sequential position indicator (1, 2, 3…) that reflects the step's current place in the pipeline. It updates automatically when steps are reordered and is intended for visual navigation in the designer and for following execution order in activity logs. Step Numbers should not be used in Jinja expressions. Reference ID Step Number Format aa, ab, ac… 1, 2, 3… Changes on reorder No Yes Use in Jinja Yes No Primary purpose Expressions, logs, field usage Navigation, execution order Step outputs should be referenced in Jinja using the Ref ID: {{ aa.field_name }} Because the Ref ID is permanent, this expression remains valid after any restructuring of the pipeline — reordering steps, inserting new steps, building parallel branches. The reference is unaffected by positional changes. Troubleshooting with stable identifiers Activity logs now include both identifiers. When reviewing a failed run, it is possible to determine unambiguously which step is referenced — because Ref IDs are permanent and never reassigned, the step in the log is definitively the same step in the designer, regardless of any reorganization that occurred in between. The Quick Reference widget provides a consolidated view of every step's Ref ID and Step Number, searchable by step name, number, or ID, with direct navigation to any step in the designer. The path from an error in a log entry to the relevant step in the designer is a single action. Backward compatibility Existing pipelines require no changes. Single-letter identifiers from pipelines created before this update (a, b, c…) are now treated as Ref IDs — permanent, stable, and functionally equivalent to the new extended format. New steps added to those pipelines receive extended-format Ref IDs (aa, ab…). Pipelines containing a mix of both formats are fully supported across duplication, export, and import. Implications for pipeline reliability and maintenance Together, these updates stabilize both components of a Jinja expression: the step identifier and the field reference. An expression such as {{ aa.customer_manager }} will resolve correctly regardless of subsequent pipeline reorganization or field renames in Quickbase. More broadly, the changes reduce the conditions under which routine application maintenance can introduce silent failures in pipeline behavior. Field renames are reflected automatically at the next refresh rather than discovered following a failed run. Step references in activity logs are unambiguous and consistent over time, independent of the pipeline's current structure. The information available during troubleshooting — log entries, step identifiers, field usage — is more reliable and more directly actionable. Read more in our help documentation about step identifiers and field renames.Using one field to collect data multiple times.
In quickbase, I have a field for user and datetime. There are several project status like pending, submitted, review,approved and denied. Everytime in the status field change I want to record who did the change and date time. I want to use the two buttons. submitted by and submitted datetime field to track the audit history or logs. I did try with a pipeline but there is no data being recorded. Anyone done this before?
New Forms Deisgner - Tab (Page) Title Colors
In legacy forms, there was a way to color each tab title within a form (snip 1). The resulting form could look something like snip 2. Using the new forms designer, I have not found a way to color each tab/page (snip 3). Is this no longer an option or am I just not seeing how to do it? Snip 1 Snip 2 Snip 3 Thanks....Aaron ------------------------------ Aaron B [email protected] ------------------------------
July 22nd 2026 Qrew Meetup Event
Portland Qrew is meeting Wednesday, July 22nd 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 Quickbase Bug. Anyone can show off work and cheer each other on. We ask attendees to bring Quickbase 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 [email protected] directly and he will send you a Teams invitation.Realm Admin Qrew Breakout Session Recap June 2026
Thank you to everyone who joined the Realm Admin Qrew breakout sessions on Tuesday June 23rd. Here’s what we discussed. Georgi Georgiev: Why Quickbase Intelligence was built this way Shared the product team’s vision for QBI as workflow intelligence inside Quickbase, not just a generic chatbot. He explained how QBI is designed to understand app context, user intent, permissions, and data before helping users take action. Qrew tip: Start with one real business question your users already ask, then explore how QBI could help answer it in context. James Travaglini: How admins can manage AI access with Quickbase Intelligence Walked through AI Controls in the Admin Console and showed how admins can turn AI capabilities on or off at the realm and feature level. Highlighted permissions for specific users or groups, including controls for features like AI Smart Builder, Import Spreadsheets, AI Workflows, Quick Insights, and AI Agent actions. Qrew tip: Pilot AI with a small group first, enable only what they need, and expand access as your governance model matures. Josh Miller: How AI can support realm cleanup planning Shared how he used Realm Insights and Quickbase AI to review governance signals like inactive apps, app ownership, audit log activity, deactivated users, and cleanup opportunities. Showed how he used Claude to turn those findings into a leadership-friendly cleanup plan that could be shared with IT and leadership. Qrew tip: Use realm data to tell a clear governance story: what needs attention, why it matters, who should be involved, and what timeline makes sense. Missed the meeting? Here’s the recording. Helpful QBI resources: Quickbase Intelligence Pack: https://www.quickbase.com/intelligence-pack About Quickbase AI: https://help.quickbase.com/docs/about-quickbase-ai AI Actions help article: https://help.quickbase.com/docs/ai-actions AI Actions overview: https://www.quickbase.com/intelligence-pack/ai-actions AI Control Center: https://www.quickbase.com/intelligence-pack/ai-control-center Knowledge Layer: https://www.quickbase.com/intelligence-pack/knowledge-layer Thanks again to Georgi, James, Josh, and everyone who joined. We’re excited to keep learning together as the Qrew explores how to incorporate new QBI features and AI tools to make managing realms, apps, and workflows more efficient. The Qrew is on Summer Break July 2026! No virtual Qrew meetups next month, but we plan to be back in August with a new topics and cadence of meetups for us to get together on.
