Welcome to the Metro Atlanta based Qrew!
We're here to share insights, gain experience, build connections and just generally have a positive impact on each other's Quickbase journey.
Welcome
Group Content
August 2025 Qrew Meetup Event
Portland Qrew is meeting Wednesday, August 27th, 3PM PST at Harder Mechanical Contractors and also on Teams. This month we'll look at DocGen lessons learned. We will also check in on moving Pipelines and setting up a separate Notification. Additional performance improvements will be shared. Finally a look at Grid Reports for those who don't have beta. We will talk about current projects, new changes and challenges. 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.July 2025 Qrew Meetup Event
Portland Qrew is meeting Wednesday, July 23rd, at 3PM PST at Harder Mechanical Contractors and also on Teams. This month we'll look at DocGen lessons learned and alternative solutions. We will also check in on moving Pipelines and setting up a separate Notification. We will talk about current projects, new changes and challenges. Anyone can show off work and cheer each other on to higher heights. 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. Near Laurel Hill, ORJune 2025 Qrew Meetup Event
Portland Qrew is meeting the forth Wednesday at 3PM PST at Harder Mechanical Contractors and also on Teams. This month we'll look at DocGen lessons learned and alternative solutions. We will talk about current projects, new changes and challenges. Anyone can show off work and cheer each other on to higher heights. 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.May 2025 Qrew Meetup Event
Portland Qrew is meeting the forth Wednesday at 3PM PST at Harder Mechanical Contractors and also on Teams. We will talk about current projects, new changes and challenges. Anyone can show off work and cheer each other on to higher heights. 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.April 2025 PDX Qrew Notes
Attendees: Barry Dolan Seattle, Kennedy Maxey, Lee Gilmore, Jen Clarke, Jim Harrison, Pat Wenger, Jacob McIntyre, Elena Larabee There were no collaboration challenges this month. On the plane back to Portland a fellow Empower attendee said hello when he noticed my Quickbase shirt. I mentioned PDX Qrew and invited him to attend, welcome Barry Doland! After brief introductions to Barry Dolan who joined us via Teams from Seattle we moved into discussing Empower. Empower Recap, Jen said she didn't really learn anything but enjoyed the chance to meet other QB builders and see how they use Quickbase to get work done. Jim also found Empower was good for meeting people. He learned that Harder has built an advanced system using Quickbase. Pat then expanded the conversation on what Harder has built and then moved on to more of a discussion about different use cases and the intentions of using Quickbase at Harder. Next we moved on to talking about using AI in Pipelines. Jacob gave an example of how they are recording online meetings and then putting them through a pipeline that uses AI to analyze and "score" the conversation. An example was given where a sales meeting is recorded and then scored or compared with other sales meetings. What they are finding is in some meetings the sales representative provides good information and the conversation covers many Quickbase features and appears successful. In other meetings the conversation doesn't go as well, information is missed or not included and the meeting doesn't go as well. It was an interesting example to consider and as I write this it seems obvious that some sales calls will go better than others for so many reasons. Part of sales is having the ability to react and move with the customer, sometimes the customer isn't interested. The area where AI may be beneficial is in helping the Sales representative to understand where they may have missed a que in the conversation, per se. I hope Jacob and team continue to investigate this example and look forward to hearing the fruit it bears. Next Jacob asked Pat about Empower and Pat talked about what we are doing with Quickbase. The conversation lead off into the realm of software platform comparisons. An example was when some of the Harder Team went to Groundbreak (a Procore sales event) to look at Procore and compare it to Quickbase. The questions or goals of the visit included answering topics like, What is the state of the Quickbase development processes versus other products? What is the business model that allows for success with Quickbase? One area that came up is the challenge of collaborating within departments. Some organizations are separated by walls of policy and the process of change takes patience. We talked about the value Quickbase provides to a company willing to break down walls and bring collaboration into the processes. Is it better to develop an in-house product with consultants or is it better to build a product using Quickbase with a team that takes on the challenge and owns the process? Quickbase is a solution for a company that has a leader committed to building a solution in Quickbase, a team of intelligent, curious and productive builders and a supportive environment in which to build. Part of building in Quickbase is the long term investment required to actualize value for the business. Other products provide value more out of the box but the business is required to change around the product and there is little to no customization without cost. Once the team learns how Quickbase works, it doesn't take long to train new builders and help them be successful. Quickbase tends to be more organic and malleable to a business willing to make the investment. The conversation wandered around these areas for a few minutes. Barry mentioned that having the understanding how the data is structured is also important for supporting business. The data entry side of understanding and solving when something doesn't work and how it tends to be the data that is the problem more so than the software. We then heard from Lee and Elena regarding their experience with Procore. One observation was it can be used as long as you are able to spin up a separate pipeline for each Job. One Pipeline per table per Job. Could it be done with callable Pipelines? One challenge we discussed for example is Invoices from Procore into QB. We also talked about pushing RFI's / Invoices in or out or Procore. Observations around leveraging the API. Getting data out of Procore or putting data into Procore. All of these use cases are challenging from the experiences shared by Lee and Elena. Jen mentioned excitement about the Pipeline integration with Bluebeam. Pat mentioned we use Egnyte for drawings and markup. He noted it could be interesting to use Bluebeam to perform markup and see how it compares with our current process. While we discussed Bluebeam Jacob mentioned it may be possible to create our own channels or connectors in Pipelines. This is something Harder has experience with after using Workato. When we first started to use Workato in 2019, there was no connector to Quickbase. Workato built a connector for us to develop and we worked with Workato to make improvements to the connector. Now we are beginning to do the same with Pipelines. Last we talked about another aspect of building software. One method is to take an idea, come up with a solution, define the architecture, build a Product, and then resolve problems until a stable product is reached. The other option is to get Users to define the requirements and then try to meet the requirements without an understanding of the underlying platform. Pat said it is easier to build a solution around the platform than to try to fit Users requirements. The challenge is to continue the conversation with the users to understand the needs and look for opportunity to improve the initial product. Developers then become responsible to support the product, train users and make changes as needed. During the building process there needs to be training and support for the Employees at the company. The product is an investment in collaboration and running the business. The product is then grown with the company. We ended the meeting and then headed over to Prost for more conversation and tacos.March 2025 PDX Qrew Meetup Notes
We started the March meeting with sharing updates on development progress during the previous month. Jen went first by showing a report designed to track progress and work complete on Jobs. The use case is to provide an easily digestible view for anyone with access to the realm. The report looks really nice and provides a lot of information with links to details. The goal of the report is to replace the spreadsheets used in the past. Next Kennedy updated Notifications sent to customers around warranty information. Seeing how others use the features of Quickbase to perform work is interesting. Jim talked about a Pipeline using the Restful API to get a report from Quickbase and then again using the Restful API to UPSERT changes to the table. The Pipeline takes three steps and uses the batch method in place of loops. He also shared progress on using QuNect to UPSERT to a UNIQUE lookup on a child table. Progress came to a halt when it was discovered that QuNect doesn't allow writing to lookup fields. Prior to a recent change by Quickbase to allow mapping tables using a Unique lookup field, this would have been an error. QuNect correctly made certain the builder didn't attempt to write to a lookup field. Now that writing to a lookup is allowed, QuNect is working on a solution and should have an update next week. Elena shared her work with Fast Field forms. She is building a solution for a customer. One problem was found problem with inserting a string value to a field. There is an option on the Fast Field form builder to insert a string literal. The string isn't written to the cell correctly. The workaround is to add a hidden field to the Fast Field form to take the place of the literal and then upsert that to QB. As we discussed Fast Field we moved into a general discussion of sharing our experience with Fast Field. The general talk about Fast Field includes a brief overview of the upcoming OCR feature. We have some interesting use cases to test out and determine if the Fast Field feature is preferred to the other offerings available in the market. During the conversation, Kennedy asked about Fast Field in general as her company doesn't have access. We gave a brief overview of Fast Field and then went over the features and differences between Fast Field and Quickbase. It seems like Jen has the most production level Fast Field experience amongst the PDX Qrew. Her experience in general is the separation between the two platforms causes duplicate work during development. We all acknowledge that while this integration is only a couple years old, improvements are taking place on a regular basis. As the platforms come together we expect improvements in the integration. As the Fast Field conversation died down, we started talking about the benefits and experience of using AI. We talked about how we use AI to write some code. We also shared our requirements & best practices for using AI. The conversation then moved towards an interesting AI use case. Elena shared a code page for designing a gardening layout planner tool. The page uses the Open AI pipeline channel to fill out record data based upon how the garden is drawn by the User. The Code page is a draggable quadrant like a square celled excel spreadsheet. Users draw a garden plan into the quadrant. Then using a header with drop down lists to define plants, soil type, that are in the selected cells on the quadrant. Next the code page generates values to be inserted into a table in Quickbase. Some of the feature ideas were to include suggestions from AI about plant placement, watering, soil all based upon the plant type in the generated records. The User now has a document with facts about the components of the garden design. It's a neat idea! The problem appears when the amount of data becomes overwhelming to the AI. The code page is generating a json array to send to OpenAI and that is where it seems to not work. The problem with the example is the number of key value pairs became too large and the AI was unable to process the data easily and at a reasonable cost. Good feedback from Jacob is to use the image itself or convert the data values into a series of questions and send the questions to open AI to produce the results. The reasoning is that AI is build upon language and may be more effective/ efficient than sending chunks of data. We all were pretty excited by this observation. The meetup began to wind down and we were beginning to say goodbye when Tammie King appeared in the Teams call. Since Tammie snuck in late, she asked about the cool excel like code page. So we talked about it some more. Again, we all were pretty excited by the garden designer code page. Then we talked about hanging out at Empower and then we called the meeting to a close. Jacob recommended the Pocket Pub as he felt it was nice the last time. While at the Pocket Pub we were witness to a storm front rolling over our heads. The news forecast was for tornadoes, lightening. The weather event was windy for about ten minutes. Some of us got dust blown in our beer before we could cover them with our hands. Then it rained and we continued our conversations.April 2025 Qrew Meetup Event
Portland Qrew is meeting the forth Wednesday at 3PM PST at Harder Mechanical Contractors and also on Teams. We'll talk about Empower a little more, key takeaways, plus deltas and other interesting gossip. Then we will talk about current projects, new changes and challenges. Anyone can show off work and cheer each other on to higher heights. 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.February PDX Qrew Meeting Notes
Diego Alvarez, Tammy King, Pat Wenger, Pierce Wagner, Nico Cantillo, Lee Gilmore, Jonathan Miller, Elena Larabee Intros Diego Alvarez was the first to present a problem. He is working on a formula to compare date values between a set of fields. The difference between dates determines a duration between start and finish and is displayed as a number of days. The collaboration energy was strong with this one as we all discussed and postulated the best solution. Tammi really took the lead with assistance from Pat, Lee and Elena. In a few minutes we had a working formula and we were ready to move on to the next problem. Pat and team Harder have been working on understanding best practices and methods of improving Dashboard report loading performance. We have many Dashboards containing gauge reports that are struggling to load. Some reports we call My Reports, filter by the current user. My reports allow each user a custom experience. Quickbase tells us the username lookup is likely the cause of the problem with slow load times. As a group at Harder we have discussed this many times but are still unclear on the logic behind the recommendations of using the email address over the QB Username. Quickbase recommends using the email address with a ToUser() formula versus using the QB Username. At the Qrew meetup, no one had a solid explanation and we weren't certain how to explain why one works better than the other (this is going to be my Elephants Child at Empower this year). One response from Lee was to use a User table, which is pretty much what we have with our Employees table. We use both User type fields and an Employees table in various locations throughout the realm. The easiest way to set up a nice gauge report is to use the User field, employing an Employee table is more complex and takes longer. Another solution is to use a Formula check box to identify where a User field in the record is assigned to the current user. In this case we use the formula UserToEmail(User()) to inform a check box. Then in the My reports filter we look for is equal to in place of is current user. The same filter is applied to the Gauge report as well. The explanation is that the formula does all the work once, whereas the is current user performs the same work for each report. I would really like to see a visual representation of how this works. Next Jonathan was asking for Kennedy. Kennedy wants to know how to transfer a pipeline from one account to another. There are many variables involved in answering this question. But here is a tldr general answer below and we can work on this at the next PDX Qrew meetup. If the email address is owned by your company, then to transfer Pipelines over to another account, as a Realm Admin, change that email to a service account. If the email is not on your domain, log on to that Users pipelines and transfer them manually. Below is how to transfer manually in several steps. First export the YAML. Next setup a service account. Last replace the slugs and import the YAML to the service account. The goal is to replace this part of the YAML called a slug: iAmasLuG and then import the modified YAML to the desired account, preferably a service account. # Account slugs: # - quickbase[iAmAsLuG]: Click "Profile and preferences" located in the upper right corner of the dark grey App bar Select Impersonate a user and enter the user to impersonate (the transferring away from account) One at a time, click the pipeline to export Click the kabab icon Click export Click "Download all YAML" or select all the text inside the black background in the Export Pipeline window and save it to a text file Once all the YAML is downloaded, open the YAML in VS Code or Notepad++ Find the all the slugs in the text and replace with the one from the service account What service account? Read on. Create an alias User: Have IT add a publicly accessible email address to your domain as an alias forwarding to one or more Users who will access the Pipelines Verify the email can receive email from outside the domain by sending an email to the address from gmail or some other email service. If you get a bounce email, tell IT to make it public Add the email as a User to Quickbase On the Users page of the admin console, locate the email Under authentication select Use Quick Base to manage password ~ wait for the email The registration email is sent to the alias email and then forwarded to you Click the register link and fill out the form with information. Record the information in a secure location like Roboforms so others can access this information in case you win the lottery Make the alias email into a service account: Admin console > Permissions, add the User to Permitted Users and groups with Build Pipelines and Create user tokens toggled on Admin console > Users, search for the Alias User, click on the User so the sidebar pops out In the sidebar scroll down and toggle on "Use as a service account", add whoever needs access to the service account Refresh the page and look at Profile and preferences dark grey upper right, there should be a Switch Accounts section and the alias is listed in that section. At this point you have all the Pipelines YAML now you need a slug. Get a service account slug: On your account click Profile and preferences, click switch to service account Once connected as the service account, click Profile and preferences again Click Channel accounts On the channel accounts page copy the Account slug to Quickbase connector Open each of the Pipelines and find and replace the old slug with the service account slug On the service account import the modified slug YAML files Test the import Turn off the old Pipelines Turn on the new Pipelines Switch back to your account Easy right? To be fair, once the process is understood, it is really easy to perform and can be done in a few hours depending on the number of pipelines to move. Also this process is only going to happen once because from this point forward everyone is using the service account and no one is adding Pipelines on their account. @Kennedy, join us for the next Qrew meetup and we can walk through the process. Next Elena shared some interesting methods around using the Quickbase Document Generation (doc gen) "Document templates" tool. She talked about solving the problem of combining individual PDFs into one pdf output (we call it bundling at HMC). The process is done using the Document Generator Restful API. A JavaScript code page is written where one generates PDFs on multiple child records via URL parameters. Then sends the separate PDFs to a PDF microservice like Convert API. Convert API loops through the PDFs and combines them into a single document. The final document is put back in a record in the App as an attachment. For Elena's solution the use of Chat GPT helped complete the JavaScript process. Elena is using PDF Lib to perform the bundling. The only caveat to this solution is file size. If the combined file size is greater than the allowed file size (50MB last check), this method does not work. Informing the User who clicked the button of the error is the next problem looking for a solution. In regards to security and uploading business files to microservices, it is not certain who has access to the files uploaded, further investigation is recommended. Nico also has customers who are using the Document Template feature in Quickbase. He mentions the cell height is limited to 50px statically and cannot be changed (without effort). He was unable to explain why 50px is the defined setting and was equally confused. Maybe someone at Quickbase can explain the 50px baseline and why this value was not given to the builder to decide. Finally we discussed a Pipeline question relating to whether it is better to batch update or loop update records on a scheduled pipeline. For this problem I have a garbage collection process where I want to schedule the clearing of values entered in different fields after a condition is met. In this case, we have employee records where one or more Employee's are Onboarding and upcoming dates are filled out prior to Onboarding date as a mean to prepare. The Pipeline looks for records two weeks after the onboarding date and clears the date fields. In my experience with Integration Reads, it is more efficient to batch update over loop update. I started a Pipeline using Resful API to get a report. Once I had the report I wanted to parse the JSON in the report to prepare a csv for upsert with blank values. The entire group suggested this method was easily done with a formula field and a search and loop update records Pipeline. I still would like to see if it is possible to get a report, make some changes and then batch upsert at some point in playing with Pipelines. Overall the meeting went really well and it feels like we solved some problems. Afterwards we decided to visit Eem and continued our conversation around Quickbase life the Universe and everything.March 2025 Qrew Meetup Event
Portland Qrew is meeting the forth Wednesday at 3PM PST at Harder Mechanical Contractors and also on Teams. We'll talk about Empower a little and maybe make some plans for the event. Then we will talk about current projects, new changes and challenges. Sometimes we show off our work and cheer each other on to higher heights. 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.January 2025 Meetup Notes
Attendees: Kennedy Maxey, Esther LaVielle, Nico Cantillo, Jen Clark, Daniel Jeon a Denver Quickbase builder 12-14 years, Elena Larabee & Jim Harrison We held the January Monthly Qrew meetup a week early as planned last month. Next month we go back to the regular fourth Wednesday schedule. The meeting started with Introductions. A new attendee Daniel Jeon joined us remotely from Denver, CO. Daniel has several years of experience with Quickbase. We are excited to hear what insights he has to share. Everyone had a chance to say hello to Daniel and give a brief introduction as well. Once the introductions were complete we moved on to asking if there were collaboration questions from the group. Collaboration: Jen asked about anyone's experience with setting up Single Sign On using Microsoft Active Directory. The example showed her login process takes three clicks and doesn't keep the login active once the browser is closed. Several commented there are some settings in the Admin console and Quickbase Support may have to make some changes on their end as well. She is planning to contact Quickbase Support. Nico Showed an App he built this past month around the management of stringing tennis rackets. The design is to keep track of materials, cost and time spent on each racket. During the presentation Kennedy asked about the Document Template. Nico explained how he is using Document Template to print forms. Kennedy looked and doesn't have access to the Document Template since her Realm is not on the plan that offers the Document Template feature. We suggested either a Builder Account, make a test, show it off and see if there is budget or Nico is going to see if Quickbase can turn it on so she can test it out. Daniel asked about Webhooks. He wanted to know if they are "really" going away. Nico responded that yes Webhooks are going away as Quickbase wants traffic going through Pipelines and not Webhooks. I pointed out that Webhooks are going away from the UI and moving forward will be managed via API. There is still a lot of work to be done before Pipelines is ready to replace Webhooks. We then talked about Zapier, Workato and Pipelines. Daniel has experience using Zapier and I asked about the experience since we use mainly Workato. He said the UI/UX is more feature dense than Pipelines, there is a Dev and Production environment for example. Next Jen asked about ideas for building a tool management system. The idea in essence is Users fill a shopping cart with Tools and then check them out. As the checkout process happens quantities are updated in an inventory table. Elena has the most experience with inventory management and building tools in Quickbase. She mentioned using a Code page. We talked about using code pages and Quickbase API to get records from a Query and then add the template new records to another table as well as update the quantity values. This is all possible with a firm understanding of JavaScript. Pipelines is also an option but doesn't provide a live real time experience for the Users. We talked more about Code pages, service accounts and performance tools. The last question came from Jen regarding a new Pipeline process. The idea is getting the most recent files from a SharePoint folder. We looked at several examples of the file structure and the recommendation came up to use Bucket. I have an example I can share but it has been a while so we decided to hold off and look at it again at the next meeting Jen is available. We arrived at the end of our meeting and said our fair wells until next time.
About Portland (OR) Qrew
Come meet up with members of the Portland, Oregon Qrew here!
Open Group