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.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.Qrew December 2024 Meeting Notes
We started the meeting giving our general status on what accomplishments we made this month. I would say the overall theme this month was everyone was busy. Due to being busy, not a lot of Quickbase work was done. We started off giving general updates with Dorian. Dorian spent some time this last month learning more about Quickbase. He is taking online QB Training and setting up a builder account. It will be exciting to watch Dorian progress through the learning process. Next we heard from Kennedy. Kennedy has been showing the Quickbase feature set off to other Big Sky stakeholders. One of the best ways to build interest in what Quickbase can do is showing it to others. When showing it to others, they start asking if it can do this or that and that builds on the development process. These simple questions may seem daunting but write them down anyways. Our brains process information at different rates. Sometimes it takes a while to think of a solution. Next thing you know, you're building and supporting an entire infrastructure the business relies upon to get work done. Next Diego talked about his experiences this month and had some really interesting questions for the group. Diego is getting comfortable conceiving and building structured systems. He shared observations on Users asking for changes and having to re-design a structure that is already in place. Another observation is finding what is already built and hasn't been used. Finally there is what needs to be added and how to do it in a way that gets used and still performs. Jen talked about building out some Apps for the service department and some UI improvements. She did a lot of building this month. She also has been working on integrations with Power Automate and HTTP connectors in Pipelines. Lee Gilmore made some comments regarding New forms versus Old forms. Learning what works for the old form versus the new form UI/UX and becoming familiar with the changes. We all agreed there is no reason to move to new style forms until Quickbase provides the same feature set as the old style forms. This feature set includes mobile functionality and form edit mode grid edit with sub-form rules. Sadly this leaves User experience in this strange state of unfinished partial solutions. Quickbase no doubt wants to proclaim new forms done and deprecate the old style, but doesn't seem interested in pushing New Style forms over the done line. Hopefully next year we will see some improvements to user experience. Elena spent time last month learning about Marketo. Also her team is working towards building a common data model for the Construction Apps in the Exchange. She shared her experiences learning about the complexity of designing the distributed data model with scalability in mind. The development of the Apps in the Exchange is complicated by answering questions like "how complex do you built it" and still have it be flexible enough to meet general requirements. At this point in the meeting, Diego asked Elena a question regarding overall decision making for product development. The question triggered an interesting conversation where nearly everyone had something to say. The question he asked; Who are you talking with to determine what solution to build and how deep you need to go? Diego then asked about how to communicate with stakeholders who aren't really interested or don't give feedback . Lee said treat the communication or lack thereof like an intake form. As builders we want to help and provide a solution. The problem happens when we get lost in the solution and are unable to provide what they are asking. It is important, and challenging, to listen to others commenting on our work and focus on their words, not a solution. Sometimes people are asking or saying things because it is how they process whatever it is we are showing them we built. There doesn't always have to be a solution. After that we went on to talk about other experiences we have working with others. Meeting with people and listening to their ideas. One interesting observation is people don't have a full sense of control over data in Quickbase. Having confidence in the data is important to getting and keeping User interest. It is easy to identify the lack of confidence when Users want to download the data and process it themselves in Excel. The challenge as a builder is to design User confidence in the data. We continued talking about how to structure data. Planning and best practices. Next Jim talked about progress on building a new Subcontractor form and process named Subcontractor Prequalification. The idea allows a User to formally request a Subcontractor is added to our Work Order system. The process replaces the current system, which is based around email, Teams and phone calls. The goal with the Subcontractor Prequalification process is to locate the information in a single database with progress alerts. Users can choose to receive Notifications on status changes, ask for status updates, stop getting notifications or learn when the Subcontractor is or isn't added to the system and why not. A benefit to this process is we now have a datastore of previous requests anyone can review before putting in a duplicate request. There were no collaboration questions this month for Quickbase development but it felt like we came together discussing Users and right sizing app building in general. Overall it was an interesting conversation, covering a problem that is complex and challenging. Any professional builder has had to deal with questions that have nothing to do with building the software part of applications. How much satisfaction does the builder provide the User versus calling it done? Afterwards we went to Broadway Grill & Brewery and continued the conversation eventually leading in to tales of upcoming and past travel. We decided then the PDX Qrew meetup next month will also be a week early and then fall back to the fourth Wednesday in February.January 15th PDX Qrew Meetup
Portland Qrew is meeting a week early again for the dark months. The plan is to 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. We do not record or AI these meetings.November 2024 PDX Qrew Notes
Attendees: Dorian Gibson GSM - Jen Clark GSM - Lee Gilmore QB - Jonathan Miller QB - Elena Larabee QB - Nico Cantillo QB - exec cust success Esther LaVielle QB - QB Kennedy Maxey Big Sky Montana, joined last year, subs, project management Tammie King - work tracking apps, client transfers Pierce Wagner HMC - Jim Harrison HMC - Diego Alvarez HMC - Big Qrew this month! Many attendees from Quickbase came to the event to see Johnathan Miller. Unfortunately Jonathan was held back by the storms of fall in the PNW. To give some scale to the events, there were hurrican force winds at the coast and we made the news-drama! Better luck next time Johnathan. Luckily we have Teams and got to see Jonathan safe at home. We started the meetup with introductions and an opportunity to talk about ourselves, where we work and what we do. After introductions we asked if there were any collaborative or problem solving questions from the Qrew. Tammie K said she had some questions about time, as in what is Quickbase time and how to handle it in Notifications expected to send during local time programmatically. Good Question Tammi! The time problem is in the Photo Shoot Scoop App. The App is a scheduling tool with reminder Notifications. The App uses EOTI for Customer access and an Internal App for photoshoot process management or scheduling. One feature sends a reminder email to the photographer the night before the photo shoot. The uncertainty appears when asking how to calculate the correct time to send the email in Pipelines. The uncertainty continues on what happens to the email time when daylight savings time changes. These are very good questions Quickbase could spend a help page explaining expected behavior of time and how to manage the problem globally and locally. The current solution is to press the button a day before the shoot at the right time. Lee Gilmore had and idea and some information at the ready. Lee said time setup is available in the new custom email feature allowing specifying a send time. The details to the time setting is it is in UTC. We were not certain how to handle time zones and changes due to Standard or Daylight savings. Also several attendees mentioned that Pipelines time is UTC and Builders really want to use a formula to determine local time. I would love to see an article in the QB Help that investigates the detailed scenarios for this time problem. Time is not easy to solve, it is generally easier to use UTC globally and then make corrections at the local instance. Next we had a new Qrew join the event from Montana. Kennedy M says they are rolling out a database. The database is designed to handle warranty tracking for real estate properties, job locations and current or upcoming projects. The system uses EOTI for customer login. We are looking forward to hearing more from Kennedy in the coming months. Another new PDX Qrew name, Dorian G also attended remotely. This month the introduction and update is they are maintaining current processes and getting comfortable with QB. It takes about a year to get comfortable with Quickbase and we look forward to being a part of the experience. This month Jen C is working on variances in inventory, how to manage inventory, working with a Customer (co-worker). Service App on FF. Diego A is currently working on Pipelines and running into an error. The Pipeline step to search a table is confusing in that the next step pretty much requires a loop through the results. Since Pipelines allows Builders to Search Quickbase and not add a loop it is easy to get into a state where the process fails. I suspect it is part of learning how to low-code ones way into a solution. Learning Pipelines is next level in Quickbase and takes time. It's good that Elena was able to provide an answer and Diego is back on the way to completing the Pipeline. Pierce W says this past month has mostly been working in Workato. Jim H gave an update on a SQL process. We have a Training Library and genreate Training records for Quickbase Users based upon their Job description, it's complex and was written using variables and a WHILE loop. The old method was very slow and limited in scale. The new method takes advantge of Uniqueification and UPSERT methods recently released by Quickbase and it is awesome! In other processes that once took thousands of Integration Reads and minutes to complete, we can UPSERT an entire dataset and instantly update or add records all based upon the unique field and not the record id. Next Elena mentioned the kanban overlay is working. We got a demo and the page is looking very professional. Code pages are really an end game for the low-code builder, releasing them from constraints built into the Quickbase UI. In Elena's example a dashboard with an iframe loads a code page designed as a Kanban report replacement. The features setting the Code page apart from native Quickbase Kanban are impressive and really should be how Quickbase offers these solutions. The nice thing is Quickbase offers a solution for the Builder to make it all work all based upon gumption. Another attendee Jonathan M gave an update on the roof and an introduction. Jonathan is now the PNW Quickbase rep, congratulations! This month was spent planning for this new position, Qrew meetups and learning about tire chains. We are happy to hear the roof is good. Nico C just came back from a Customer Qrew Okto engagement. The event focused on using Document Creation & Secure Links to provide a solution for a Contract life cycle form. Nico was really excited about the solution and wanted to give a presentation. The soultion uses Secure Links to EOTI in this case a Vendor. The Vendor opens a form, fills out the form and submits it back to the Owner. The Owner receives the form, does some work and then sends a printed document to the Vendor. The solution also allows for setting end dates to expire the link, meaning if EOTI gets a hold of the link it may not work. Esther L gave an update on scheduling all the Qrew meetups for December. Next goal is getting more presenters at the events. Lee G gave an update on the Thanksgiving planning app. Everyone agreed Marshmallows do not belong in Macaroni & Cheese. Last thing I recall discussing is the announcement of Empower 2025. Empower is taking place in New Orleans. Event dates are March 31 & April 1st. Some mention was made that Ben Simon is planning something with Beignets, we look forward to enjoying some Beignets with Ben. We went to the Pocket Pub, Lee likes it and the Jalapeno Poppers are very nice.October 2024 Qrew Meetup Notes
Qrew meeting attendees: Elena, Diego, Jim, Lee, Nico, Jen, Pierce Nico Cantillo a Customer Success Manager from Quickbase joined the PDX Qrew this month. It's an observation that all the Quickbase representatives I have met in the past few months are curious and interested. I find they are asking questions about our experience and looking for feedback. Some questions came up around our opinion of Empower Pro, what did we like/dislike and of course to Give Feedback. Quickbase'interest and engagement does not go unnoticed. We started out the meeting with Introductions all round. After introductions we each shared our progress or improvements in the previous month. Diego began with updates he is making to Dashboards. Recent Quickbase updates to Dashboards, we have been adjusting our Dashboards from the "New Style" to the "New New Style". The layouts have changed and we have noticed performance problems causing additional testing and changes to the previous design. For example, it used to be that displaying a report on a Dashboard didn't cause the Dashboard to hang for seconds on load. Since the updates, we are removing reports from Dashboards to improve load time performance. One observation is the "Performance Monitor" doesn't work on Dashboards, so there is no low-code way to tell the Builder what is causing the load problem. In some Apps we have Dashboards that act as "single pane of glass" experiences for Roles and there are several Roles in the App. Diego, as well as others on the HMC Team are busy with these modifications. Stemming from a question of whether Dashboard tabs on top are an improvement, we moved away from introductions for a little bit. We talked about Give Feedback and some of the experiences with that feature of the Quickbase platform. Anyone who spends more that fifteen minutes looking at Give Feedback finds ideas that have been untouched for years, other ideas are closed almost immediately without a way to respond. Give Feedback is hard for Users to find and one cannot share links without problems for anyone who clicks the link. Lastly the frustration around convincing Quickbase Support there is a problem only to be told to go create a Give Feedback. This behavior makes the Customer have to duplicate the same work in two places. Nico was very nice and created a Give Feedback regarding the tabs on Dashboards taking up the space gained by removing the Global table bar (Quickbase giveth and Quickbase taketh away. :) Next Lee gave an update on progress last month to say he is traveling quite a bit. He did have a problem, which we got to after the updates portion of the meeting. Jen said last month was about trying to rework a summary report to pull averages from a specific static time period (which is not the native functionality). We did some brainstorming on better ways to get there with a formula, and she was able to sort it out the next day. No update on the Fastfield buildout. Finally she is excited about new mobile forms but needs embedded reports to be included before migration can begin. The builders who use embedded reports and Grid Edit all agreed this is a show stopper for migration. Jim has been working mostly in SQL updating a QuNect Stored Procedure to use unique fields to perform bulk imports. The goal is to reduce Integration Reads and speed up processes significantly. This is a long term transition as there are many automations using the loop method to add/update records, all which need to be switched to the bulk import method. Elena was excited to share something interesting. She showed her method of using an iFrame to load a Code Page that has features outside of the Quickbase feature set and also uses Parameters. The iframe displays a report. In the report is a button. When the button is clicked, it opens a pop-up window with a Drop Down List. The pop-up list looks modern and has some features like showing what is already selected. We talked about using "OpenAsAPopUp" and ifv but the limitations on native Quickbase Drop Down List styling could not be ignored. Pierce shared he is working on redirects. The challenges associated with getting redirects to work in different situations. Pierce is one of the newer Quickbase builders at HMC and has more SQL experience, which is greatly needed and appreciated. We then briefly talked about changing the Qrew meetup dates by advancing one week for November and December. The change was agreed upon unanimously. Next we moved on to a problem Lee wanted to work on. He has this complex formula that determines the editability of a field based upon a date range. Diego put a solution in the Teams chat that hopefully Lee can modify to meet the requirements. If not I have a feeling November PDX Qrew will be working on the formula, which sounds like a good time. We ended the meeting and called it a day. side notes: We often have this conversation about Quickbase UI/UX limitations. When a customer reaches the limits of Quickbase, one option is to move into Code Pages, if they decide to stick with Quickbase. There is a comprimise to Code Page or not to Code Page and each organization should consider this seriously. The queston is: If we move to Code Pages, we either need to get good at reading the language in the Code Page or Pay someone to help maintain it for us. I think it is an interesting long term conversation. I also think it is essential to have the Code Page as an option.September Portland Qrew Meetup Notes
September Portland Qrew meeting started at 3 PM PST on a beautiful fall day. Attendees were Lee Gilmore, Jonathan Miller, Jen Clarke, Jim Harrison. Elena Larabee and a couple last minute invites Jonathan thought would benefit from the experience (KennedyM (Wyoming/Montana), Ender (Denver Co)). In the end the last minute invites didn't make it but I wanted to make note of the invitation to track how this develops. After saying our hello's and introductions, then finding there were no collaboration problems to solve, we reviewed the past months progress. Starting with Lee explaining how he is working on last minute projects, trying to finish something for a customer, and so a little distracted. Having children who attend PPS we are well aware of in-service days where there is no school and Lee was attending remotely. Lee said he will be at next months meeting if all goes to plan. Jen talked about making preparations to building out a Mobile solution. Part of the month was spent comparing Quickbase versus FastField Forms on the iPad. It sounded like the conclusion is FastField is the path forward. Licenses are purchased and they started to learn the FastField UI. The project goal is to provide field representatives with the ability to enter work orders electronically. It's exciting to hear about the development of an electronic, wireless data entry and processing system custom built to the company's specifications. The amount of design that must go into what sounds like a simple project can be overwhelming. We are looking forward to hearing what Jen discovers and are standing by ready to assist and be awed at the design ingenuity. Elena talked about efforts with trying to move data between Domains. In this example, an iFrame in a QB Dashboard that opens an O365 scheduling tool ~ sort of what Tammie was working on previously. When a User clicks the scheduler, the Scheduler page is supposed to open. Instead there is an error because of a security feature in the browser to disable cross site scripting. Aside; for a while Website builders could steer Users away from one Website and to another Website. The method eventually was used to steer Users to nefarious Websites where data loss could happen. Browser builders put a stop to Cross Site Scripting and named it CORS and the Internet moved on. We talked about the inherent problems and shared the limited understanding we have of leveraging Oauth and other security methods to solve the problem. This problem is another of those "sounds easy" until you try it challenges most developers come across regularly. When Elena comes up with a working solution, we look forward to hearing how it was solved and taking notes. Elena also started on the path to discovering Jira www.atlassian.com a project management tool and is still in the early stages of determining how it's supposed to work. Next I shared my progress in the past month. My main focus has been updating stored procedures that use QuNect to sync data between different services in the environment. As is normal with managing data synchronization, there are always requests to add another field to the sync so some other process can be built out for some reason. My method when making these changes is to review field comments, and update notes as needed or where lacking. Over time it is much easier to manage complex systems if there are bread crumbs of knowledge. Also this month we had an amazing opportunity to bring together a large group of Users at Harder and talk about how they use the systems we have built. We called it the "PRIME Improvement Team" event. The event was 3 days of talking about PRIME (our custom Quickbase solution) and listening to our Users. The event was well received by all attendees with requests for more and a lot of new work for the development team based upon the conversation. Finally I shared my experience with the new Quickbase Support Website and gave a rundown on the plus deltas. We wound down the meeting talking about Forms, new style vs old style and form rules in general. Basically with old forms it was nice to have all the fields in a list to manipulate and a pita to manage form rules. We touched on the challenges to transitioning over to new forms. The difference in performance between the old and new forms (old forms are faster). Finally we discussed working and collaborating with development teams . When working with a team of developers there is an extra layer of responsibility amongst the team to ensure all are aware of standards and what everyone is doing. Having daily standups in an open blameless environment is critical to ensuring the team is comfortable working together. It is easy to go into your cave and only come out for food and bathroom breaks. Taking time on a daily basis to share with the team engenders creativity and collaboration. Finally Jonathan Miller, who is a new Quickbase employee and first time attendee, gave some plus deltas of the meeting. He volunteered to be the note taker (thank you) and wanted to invite more Quickbase builders to the meeting. It is impressive to see the level of professionalism Jonathan brings to the table and we are looking forward to working together moving forward. Below is my BMW 1979 R65 per a request from Jonathan. Looking East from the hills on the East side of Salem, OR.Qrew Meetup Notes July 2024
Attendees: Jen Clark, Elena Larabee, Lee Gilmore, Diego Alvarez, Jim Harrison We met at 3PM on the forth Wednesday of July. The only downside was I forgot to renew the Teams invite for Tammie King and she didn't join us. Apolgies Tammie! Moving forward, I have added Tammie to all future Qrew meetups and she has already accepted. Another productive meeting we mainly focused on styling Rich Text Fields. First Diego showed what he made using the Rich Text functions method Jen had shown last month. During the June Qrew meetup, Jen Clark displayed how she uses Quick Base Formula conditions to apply HTML styling to rich text fields. Diego was inspired to create his own conditional styling and this month he showed his work. Diegos field is based upon the values in other fields. Depending on those fields values, the Rich Text field changes color and shows one or more lines of text. The use case then displays the field in a report and provides Users with action items to be completed. As the Action Items are completed the text disappears from the Rich Text field. The field is taking information from multiple fields and condensing it into a single field, meaning the report has fewer columns with the same amount of information. Next Jen had questions regarding using tables in Rich Text Fields. Jen is learning HTML "on the fly" and needed some assistance in the finer details. We reviewed the properties of the table element and covered syntax. We also looked at using App Variables to style the different elements (table, th, tr, td) and she quickly started to add to the Rich Text experience. Within a few minutes the Rich Text field had been transformed from words in a cell to a formatted table with fat red borders; Jen was having fun! We left Jen to her styling and moved on to a problem Elena brought to the table. Elena had questions on formatting a table into a "Safety Cross". She wound up teaching us all a thing or two about using ChatGPT. The styling problem is easy to solve with plenty of reiterative CSS; make a change, update the table, save and reload. Instead Elena chose to use ChatGPT to style the table properties. We learned there are nuances to getting the correct answer. The nuance is in asking the question and modifying parameters and requirements sent to the LLM (Large Language Model) .We still have to know the syntax of the code in order to verify it is properly formatted but all the little changes one makes when styling are handled by ChatGPT. The result in this example is a lot less scanning HTML for mistakes. It is these moments of discovery and sharing that make these meetings so important. Each of us are on our own journey to learning Quickbase development. Together we improve our capabilites. While we were all excited and talking about using ChatGPT I realized the time and called and end to another Qrew meetup. We headed out for some Pocket Pub minus Diego (who is not in Portland) and Elena who had other obligations. Lee, Jen and I continued our conversation around Quickbase as well as other topics.Qrew Meetup Notes June 2024
Tammie King, Elena Larabee, Jen Clarke, Diego Alvarez We started the meeting discussing our latest projects. Jen mentioned working on building a QB Mobile experience. The Harder team has also been working on an initiative for building a mobile experience for Apps in our realm too. We talked about the conversations we are having around standardizing the layout and components required for the Mobile experience versus Desktop. Diego shared the work he has done developing mobile Apps. One idea he is experimenting with is to create a scroll at the top of the Mobile App. His plan for a Left-Right Scroll is to use a report with Rich Text buttons. Looking forward to seeing the results of this idea as it could be useful in many places. Next Elena shared her experiences building service modules for the QB Exchange. The main focus has been on automating the Pipeline YAML export, re-slug and import process, which allows moving changes from Dev to Prod much simpler. This development is an improvement to Quickbase with potential. Elena talked about using ChatGPT to get formulas for Rich Text Buttons. The conversation that suddenly took place between Tammie, Elena and Jen amazing around ChatGTP was amazing. Here are some of the recommendations shared during the conversation. The best ChatGPT writing QB suggestions: Give ChatGPT the link to the documentation and then ask it to review the code. You have to know how to write YAML or Formulas and then asking ChatGPT to provide a solution you can review knowingly without having to do all the typing and error checking for typos. Next we moved on to the collaborative portion of the meeting. Jen had questions regarding HTML and Rich Text buttons. Her main focus of learning right now is verifying or becoming comfortable with the QB formula language and learning HTML. We looked at a button she is working on that changes conditional to another fields value. Tammie stepped in and showed some of the excel to QB cell shading she has developed in the past. In essence, we recognize many Users are moving from Excel to QB to do work. The builder wants to make the UI/UX as inviting as possible to improve the transition, thus we build a lot of complex buttons. Rich Text Formula fields have made it where advanced builders can customize the look and feel of the Realm. By making visual changes to the environment, end-Users feel there is greater value in using the product over Excel which improves adoption. We hope Quickbase decides to improve the Grid Edit experience as development has been stalled in this area for a few years. After we looked at formula rich text and replicating excel in quickbase we moved on to other topics. I talked about the main focus for the past few weeks to re-write a Stored Procedure in SQL (QuNect) that initializes Employee Training data based upon the Employee Job Title. It is a complex multi-layered process Harder has come to rely upon. It works based upon the Employees Title. By knoowing the Title, QuNect adds Training Records (with links to Videos and documentation) to the Employees record so they see recommended trainings all based upon their Title. The reason for the change is previously the Stored Procedure was written using temp tables and CTE's (Common Table Expressions). The goal is to leverage the newish Unique bulk UPSERT feature by creating Surrogate Keys and UPSERTing using the Surrogate instead of Record ID#. Since I am playing with live data, I am being as careful as possible to avoid phone calls, emails and QB Restore tickets. Finally I am developing a baseline template for how to use bulk upserts over older while loops. Another good meeting had come to a close and we agreed it was useful for all. Tammie says she is going to keep showing up, which is awesome! Afterwards Jen, Elena and I headed out to Izakaya Kichinto for some heart warming Sushi and Ramen.
