Resource Icons
Latest Highlights
Check Out The Latest in The Qrew
Today's installment is brought to us by Quickbase Pipelines Product Manager GeorgiPeev.
In this QrewTip he demonstrates how to use the new AI Actions Channel in a Pipeline to automate repor...
4 days ago
Starting in March, we’re updating when we roll out our monthly major release. Instead of releasing on Sunday morning, we’ll now deploy our major release at 11:00 PM Eastern Time, usually on the secon...
11 days ago
2 MIN READ
Hey Qrew! Osa here from Customer Education.
We're trying something new: QBU Office Hours
Live, 1-hour sessions where you can bring questions and work through course-related stuff directly with ...
4 days agoThe Content Feed
Feed
Building a Revenue Forecasting Tool in Quickbase
Summary Revenue forecasting often breaks down when it doesn’t reflect how revenue actually occurs. Many tools assume lump-sum revenue or rigid rules that don’t work well for projects spanning multiple months or years. We built a flexible revenue forecasting tool in Quickbase to address this and wanted to share the pattern since it’s reusable across many forecasting scenarios. The Challenge Many forecasting approaches assume: Revenue can be treated as a single amount Projects don’t span months or fiscal years Forecast logic is difficult to adapt What we needed instead: Revenue spread across start and end dates Clear month-by-month visibility Support for multi-year work A forecast that updates automatically When this isn’t supported, forecasting usually ends up in spreadsheets, creating manual effort and risk. The Approach Rather than relying on static reports, the approach was to: Store forecast data as its own records Only generate forecasts when revenue is likely Distribute revenue across the months when work is expected Let Quickbase handle recalculations This keeps forecasting system-driven instead of manual. How It Works 1. Forecast Triggers Forecast records are created once an Opportunity reaches a defined confidence threshold. Keeps early-stage work out of the forecast Focuses reporting on realistic revenue 2. Monthly Distribution A pipeline: Reads anticipated start and completion dates from the Opportunity Loops through a formula field that identifies which months and years are contained between the start and completion dates Spreads revenue across the applicable months In our current model, revenue is spread evenly across the duration, but the logic can be tailored for front-loaded, back-loaded, or milestone-based distributions as needed. If work crosses a fiscal year, separate records are created per year to keep reporting clean. Revenue does not need to be evenly spread, sometimes 3. Monthly Records vs. Monthly Fields There are two common ways to model monthly forecasting: One record per month (traditional approach) One record per year with monthly fields We use monthly fields so all values for the same year live on one record, making it easier to compare months and make adjustments without working through a list of records. 4. Staying Current Changes made on the parent Opportunity (dates or expected revenue) automatically recalculate the related forecast records When an Opportunity is marked Closed Won or Closed Lost, its forecast records are removed The forecast always reflects pending, expected revenue Why This Works Well This pattern: Eliminates spreadsheet-based forecasting Matches revenue timing more closely to reality Keeps forecasts easy to view and adjust Scales as complexity grows Reusing the Pattern This works anytime: Revenue needs to be forecasted over time Work spans multiple months or years Forecast logic needs flexibility All you need is: A clear trigger for when revenue should be forecasted Start and end dates Pipelines to generate and maintain forecast records Alistair Marsden | Solutions Consultant Website | LinkedIn | Knowledge Base
Choosing a parent from a child table
My parent table is "Change Requests" and child table is "Prompts." The prompts tables houses prompts to a chatbot and the Change requests table houses all change requests (bugs found, knowledgebase expansion etc) that stem from prompts that have a negative feedback. So each prompt could have a change request. I created a Related Change request numeric reference to link the two tables and a corresponding Change Request (Text (reference proxy) ) and this allows me to look up and choose a parent record to assign the child to. However, I first need to create the parent record before it shows in the drop down menu of the Change Request (Text (reference proxy)) field. Further, I would like to filter this drop down to only show Change requests related to that particular Bot (as the Prompt table houses data for multiple Bots). Is there a way to create a new 'Change Requests' record from within the Prompt's table? I have Prompts collected for two Bots - Is it possible to filter the Change Requests drop down in the Prompts record to only show the Change requests related to that particular bot? Thanks! Deepa
Long-Term Strategies for Data Archiving in the Quickbase Ecosystem
Long-Term Strategies for Data Archiving in the Quickbase Ecosystem Summary Organizations that have relied on Quickbase for years often reach a point where data growth, performance, compliance, and cost concerns require a more intentional approach to long-term data archiving. This article outlines practical, scalable strategies for archiving data within and beyond the Quickbase ecosystem, helping long-standing customers modernize without disrupting business-critical workflows. Why Long-Term Quickbase Customers Need an Archiving Strategy Quickbase excels at enabling rapid application development and operational agility. Over time, however, long-tenured Quickbase environments tend to accumulate: Millions of historical records across core tables Large file attachments increasing storage and sync times Performance degradation in reports, pipelines, and automations Compliance and retention risks (financial, healthcare, construction, government, etc.) Rising subscription and storage costs Without a structured data lifecycle strategy, teams are forced to choose between deleting valuable history or tolerating slower, more fragile applications. Quickbase goes from being a source of efficiency and business scalability, to a source of frustration and an operational drag. Key Principles of Effective Data Archiving Before selecting tools or tactics, successful archiving strategies in Quickbase share several guiding principles: Business Continuity First – Archived data must remain accessible when needed, without breaking existing apps. Automation Over Manual Effort – Archiving should run on schedules or triggers, not human memory. Compliance-Aware Retention – Retention rules must align with legal, audit, and contractual requirements. Performance Optimization – Active Quickbase apps should become faster, not just smaller. Reversibility – Archived data should be recoverable if business needs change. Common Data Types to Archive in Quickbase Long-term customers typically identify archiving candidates in these areas: Closed or completed projects Historical transactions (orders, invoices, time entries) Inactive customers or vendors Audit logs and system-generated records Legacy attachments no longer needed for daily operations Archiving does not mean deletion—it means removing data from active workflows while preserving access. Archiving Strategies Within the Quickbase Ecosystem Native Table-Based Archiving One of the simplest approaches is moving historical records into dedicated archive tables within Quickbase. Used for Moderate Data Volume, Occasional reporting needs, and minimal compliance complexity. App-Level Archiving (Split Apps) For mature environments, archiving entire datasets into separate Quickbase apps can dramatically improve performance. Storage app limits are much greater than singular tables and one can create multiple apps that would house data Governance, Security, and Compliance Considerations A strong archiving strategy addresses: Role-based access to archived data Read-only enforcement for historical records Retention schedules (e.g., 5 years, 7 years) Legal holds and audit readiness Encryption at rest and in transit Ignoring governance often turns archiving into a future liability rather than an asset. Measuring ROI of Data Archiving Clients typically see measurable returns within months: Faster reports and dashboards Reduced sync and pipeline failures Lower storage costs Improved user adoption Easier compliance audits Archiving is not just an IT exercise—it directly impacts operational efficiency. Next Steps If your Quickbase apps are slowing down, becoming harder to maintain, or raising compliance questions, it’s time to evaluate a long-term data archiving strategy. Logan Lott | Senior Solutions Consultant Website | LinkedIn | Knowledge Base
Auto Assign Button
I need to create a drop down on a form and have the user select what team they want to assign to and then QuickBase auto assign to a member on that team in order. So employee 1 first then employee 2 and so on until it gets to the last employee and then it starts back on the first employee and continues. I have no clue if this could happen or how to. Thanks, Carol
Social Impact Quickbase Job! 💼❤️🌎✨
Want to build in Quickbase AND make a difference? Do you love setting organizational project management strategy, tinkering with data, and interfacing with project staff and senior leadership? Apply for the Data Systems & Quality Manager role at CAI, a capacity building nonprofit dedicated to improving public health and social services. About CAI CAI provides training, technical assistance, and research to foster a more aware, healthy, and compassionate world. CAI has a rich history on the frontlines of the AIDS epidemic in NYC in the 1980s. Today, CAI is known for its exceptional capacity building around HIV, LGBTQ2IA+ health, Maternal and Infant Health, Trauma Informed Care, Sexual Health, and Substance Use. CAI is full of smart, interesting, dedicated co-workers. About the Role The Data Systems & Quality Manager works with project teams to support their project management and data tracking and with senior leaders to implement organizational initiatives (performance metric dashboards! trend trackers! etc!). You'll leverage data to support real decision making. You'll manage all things Quickbase, designing new features as requested by projects. Posted salary range is $85k-105k. If you apply, please mention you found this role on this job board! The role is posted for hybrid NYC-based. Exceptional remote candidates considered. https://workforcenow.adp.com/mascsr/default/mdf/recruitment/recruitment.html?cid=203d7116-60b4-45eb-a5ab-59f73d56112b&ccId=19000101_000001&jobId=657518&lang=en_US
Sort records returned from an advanced query pipeline step?
I have a pipeline with a search records step using an advanced query. It is successfully returning the records I'm after, but I would like to also sort the results so I can grab a particular one. Is it possible to specify options for an advanced query within a pipeline search records, or am I limited to just a simple query string? The documentation doesn't mention how to incorporate other params in a pipeline just the query string. My current query string: {'3'.XEX.{{a.id}}}AND{'16'.EX.'Update'} Thanks!
Solving Filtered Multi-Selects in Quickbase
One limitation I run into fairly often in Quickbase is filtered multi-selects. Quickbase supports conditional dropdowns on relationship fields, which works well when a user is selecting a single option. The issue comes up when users need to select multiple options and still have those options filtered based on one or more previous selections. Since multi-select fields can’t be filtered, users end up seeing options that don’t apply. I recently built a solution for this and wanted to share the pattern, since it’s reusable across a lot of different scenarios. The Challenge Out of the box: Conditional dropdowns only support single selection Multi-select fields can’t be filtered Users end up seeing options that don’t apply In this case, the requirements were: Users must be able to select multiple options in both steps Only valid options should ever be shown The experience should feel simple and intuitive, not like a workaround The goal wasn’t to force something into a multi-select field — it was to keep the user experience clean while still enforcing valid selections. The Idea (High Level) The approach was to: Break the selection into two steps Let Quickbase build the valid options for the user (for example, using a pipeline) Let users select from only those valid options Rather than asking users to figure out what applies, the system does the work for them. Example Use Case Here’s a scenario people can apply this to: Step 1: User selects one or more Vendors Step 2: User selects applicable Services The key requirement: Not all Services apply to all Vendors Users should never see invalid combinations Instead of showing every Service and relying on users to know what applies, Quickbase only presents options that are valid based on what they selected in the first step. User Experience From the user's perpective: The user selects one or more Vendors The user saves/submits their changes The system generates a clean list of only the valid Services The user checks the Services they want This ends up feeling very similar to a filtered multi-select, without exposing irrelevant options to the user. Why This Works Well This pattern: Prevents incorrect selections Keeps the interface clean and focused Is easy for users to understand Scales well as options grow Works for both many-to-many and one-to-many scenarios How Others Can Reuse This This approach works anytime: Selection B depends on Selection A Users need to choose multiple options You want to hide anything that doesn’t apply What you'll need: A clear source of truth for valid combinations A step where the system generates valid options A simple selection step for the user You don’t need the exact same data model - just the same concept. Replace “Vendors” and “Services” with whatever fits your use case. April Barragan | Solutions Consultant Website | LinkedIn | Knowledge Base
Overtime formula Calculation Question
I have a time reports table that could have multiple time reports for any 1 person. Each record contains hours for individual fields Sun-Saturday. These hours could be Regular or Benefit hours. If an employee is Hourly, and they work more than 40 Regular hours across their 1 or more Time Report Records, I need the OT calculation formula to evaluate how many OT hours should be applied to the Added/Updated record(s). I have 2 pipelines built to handle this: one for record(s) added and another for record(s) updated. The pipeline copies the OT calculation into the O/T Hours field for each record as applicable. The OT calculation below works for when they are adding hours above what is already there, but if they REDUCE hours (making a correction), it does not back out the O/T Hours and I'm not sure what adjustment I need to make to the formula for this to work. Any suggestions? If([Task - Consultant - Salaried/Hourly]="Hourly" and [Consultant Total Reg Hours Current week]>40, Min([Reg Hours], [Consultant Total Reg Hours Current week]-40)+[O/T Hours],0)Introducing the Code Page Samples App
Introducing the Code Page Samples App Hello Builders! We are on a constant journey to elevate the level of sophistication that can be achieved in Quickbase. From new aggregate capabilities, Pipelines, a refreshed UI and class-leading governance, Quickbase is a truly no-code tool. But to us, no code doesn’t have to mean “code not allowed”. While we are retiring iCal and vCard fields natively, those features can be achieved with a little bit of JavaScript and our new RESTful APIs. More recently, we announced that we will be changing the way the platform handles custom content (like JavaScript code) that is inserted outside of code pages to put security first. Combining this effort with our roadmap to build extensibility, we both analyzed product usage and spoke with hundreds of builders to understand common use cases and edge case scenarios for extending Quickbase. While we aim to provide as much native functionality as possible, we have a strong set of APIs that allow builders to extend the platform and innovate. Much of this can be achieved client-side, in code pages. To help builders take advantage of these techniques, we have collected examples into a new app, the Quickbase Code Page Samples app! This app is open to everyone on the internet. Use it as a guide to better understand how to take advantage of code pages, and how they can be used to extend the platform, solving for even more use cases. As we continue to listen and learn from you, we’ll update the app to include additional examples. Please note: this app's purpose is to highlight helpful techniques for code pages, and while this overlaps nicely with the need to move away from using inserted JavaScript, the app is not intended to be focused exclusively on that initiative. Over the coming months, we will publish additional blog posts dedicated to each technique. The first one, about Using Code Pages to Refresh with a Delay is available now. These posts will explain how a given technique works, and how it can be applied to your own apps. Keep an eye out for these posts over time. Finally, please remember that these code samples are provided as-is, and are not supported directly by Quickbase. Have a great week, -The Quickbase Product team