Qrew Groups
Connect with others from your area, or who share the same role, professional interest. Find your Qrew here!
Recent Content
Jinja If else statement syntax
In case anyone else is looking for a solution to entering a conditional statement into a Pipeline as an out put value, here is what I learned today. Below is the syntax entered into the place where the {{ c.values }} are put in the Pipelines Designer page. If anyone knows what these inputs are named please tell me. {% if step.fieldname is gt(0) %} {{step.fieldname * -1}} {% else %} 0 {% endif %} Explanation: The statement above is an if : else statement. {% %} these things signify the conditional statement part and {{ }} these are the values the field gets if the condition is met. If the fieldname is greater than 0 {% if step.fieldname is gt(0) %} then enter the value from fieldname from a previous step times negative 1 {{step.fieldname * -1}} else do the next thing, which in this case is enter 0 into the fieldname from a previous step {% else %} finally end the if statement {% endif %} I looked around and couldn't find anything useful so here's a little nugget. ------------------------------ Jim Harrison transparency = knowledge + understanding : The Scrum Dudes ------------------------------Using ""&z=""&Rurl() and rdr in formula URL fields
People ask all the time, "What is the "&z="&Rurl() inside some of my Quickbase buttons?". Well, not all the time, but often enough that we should talk about it. I am referring to formulas that are inside Formula - URL field buttons like, "Add Task", "Add Document" or "Add Project". It doesn't matter if records are child or parent records you are creating. Only that you are leaving one location to manually add or edit a record and you wish to return back to the location from which you started. Workflows that require user input When creating a relationship, Quickbase automatically generates an "Add Record" Formula - URL field. This provides a quick way for users to create a child record. However, many people have edited their Add Record button and figured out that the "&z="&Rurl() seems to return them back to where they started from, but when they try using the function in other formulas it doesn't work all the time. The reason - it's not supposed to. This function was an expedient way for Quickbase engineers to pass a bread crumb from the originating URL into Quickbase so that when you were finished adding or editing a record you would have a way to return to your original starting point. There are two valid use cases for "&z="&Rurl(). One is when you use the API_GenAddRecordForm and the other is when you use the a=er function to edit a record. Bear in mind that both of these cases expect you to manually modify a record, save the record and return back to the URL from which you started. Here's an example using API_GenAddRecordForm: URLRoot() & "db/" & [_DBID_TASKS] & "?act=API_GenAddRecordForm&_fid_48=" & [Record ID#] & "&_fid_8=" & [Est Start Date] & "&z=" & Rurl() And here's an example using a=er: URLRoot() & "db/" & Dbid() & "?a=er&rid=" & URLEncode([Record ID#]) & "&dfid=12" & "&z=" & Rurl() The thing to remember about the above two examples is that you are starting from one spot, either adding or editing a record, manually saving the record and returning to your starting spot. The "&z="&Rurl() only works in this situation. Workflows that do not require user input If you are using another API call such as API_AddRecord or API_EditRecord, the format for redirecting to another page is a bit different. In this case, you can redirect the final API call in your formula to an a=doredirect URL. This takes the z=rurl() concept and makes it more valuable, since it allows you to make one or more API calls, and then reload the current page. For example: URLRoot() & "db/" & [_DBID_TASKS] & "?a=API_EditRecord&rid=" & [Record ID#] & "&_fid_7=Approved" & "&rdr="&URLEncode(URLRoot() & "db/" & Dbid() & "?a=doredirect&z=" & Rurl()) On the other hand, rdr can be used to redirect the user to a specific page. For example, after a new record is created, perhaps you want to display a "thank you" rich text page you've created. This thank you page should appear as the next step in the workflow, regardless of whether the user was on the app dashboard before they created the record, or whether they came from the table home page. For example: URLRoot() & "db/" & [_DBID_TASKS] & "?a=API_EditRecord&rid=42&_fid_7=Approved"&"&rdr="&URLEncode(URLRoot() & "db/" & Dbid() & "?a=dbpage&pageID=30") For more information on creating formulas in Quickbase you can review the documentation below, or open a support case for assistance. Further Reading: Using Formulas in Quickbase Formula Functions Reference Read about GenAddRecordForm in the API Guide Read about AddRecord in the API Guide Read about EditRecord in the API Guide
SAML Public Authentication Certificate for Signed Authn Requests
June 21st, 2024 Update: We have created a Quickbase app to host the Quickbase SAML Zip File. Access the app by clicking the link above to download the file. For Quickbase Realm and Account Administrators As a Quickbase Realm or Account Administrator, you are probably aware of how your users authenticate (login) to the Quickbase platform. Many Quickbase customers use our SAML authentication feature. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services, such as Quickbase, that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. To help you understand what you may be using at your company, some examples of SAML, SSO or IdP (Identity Provider) vendors are Okta, OneLogin, Microsoft, Duo, and there are many others. Some customers using the SAML authentication feature may also choose to use an extra layer of security whereby each authentication request from the Quickbase platform to your company’s SSO directory (or IdP) is signed by Quickbase using a public authentication certificate configured on the Quickbase platform. Quickbase refers to this extra security feature as the “SAML Authn Requests” option. It has that name because there is a feature in the Quickbase SAML configuration settings named “SAML Authn Requests”. Only Quickbase staff can see this option or change it. It is only enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. *When the “SAML Authn Requests” feature is enabled by Quickbase, and the customer has configured their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process, both Quickbase and the customer’s IdP must use the same public authentication certificate in order for Quickbase authentication to work successfully. If they do not match, Quickbase authentication (logins) will fail and the customer will be unable to use Quickbase. Once a year, Quickbase is required to rotate the public authentication certificate. The certificate rotation will occur on a specific date/time within a 15 minute maintenance window. Therefore, the certificate rotation process requires careful coordination between Quickbase and all customers who have chosen to use the “SAML Authn Requests” feature. Typically, about 2 weeks prior to the annual rotation, Quickbase will communicate to Realm and Account Administrators for customers using the “SAML Authn Requests” feature via in-product messaging and possibly also e-mail. We also post a notice on the Quickbase service page. We provide a link to this Community post which specifies in a section below the date and time of the rotation and provides a link to download the new public authentication certificate. *The Realm and Account Administrators need to contact the person or team at their company responsible for administering their IdP/SSO/SAML system, typically their IT department, in order to ensure that the new public authentication certificate from Quickbase is also installed in the customer’s IdP/SSO/SAML system during the 15 minute maintenance window announced by Quickbase. *The public authentication certificate CANNOT be changed in your company’s IdP prior to the announced maintenance window or logins to the Quickbase platform will break. If the certificate is not changed in your company’s IdP during the 15 minute maintenance window announced by Quickbase, logins to the Quickbase platform will be broken until the certificate is updated in the IdP. For Single Sign-On (SSO) or Identity Provider (IdP) Administrators: PLEASE NOTE: The remainder of this Quickbase Community post is highly technical and should be reviewed by the person or team responsible for administering the Single Sign-On (SSO) or identify provider (IdP) system used to control access to the Quickbase platform. Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials (username and password). An identity provider (IdP) system is a directory of usernames, passwords, groups, roles, etc. that is typically used to manage access to the applications used by a company. Another acronym commonly associated with Single Sign-On is SAML. Security Assertion Markup Language, or SAML, is a standardized way to tell external applications and services that a user is who they say they are. SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications. Many customers use Quickbase's SAML authentication feature. A subset of customers may have the “Signed Authn Requests” option selected in their Quickbase SAML configuration. That option is a security enhancement that results in Quickbase signing the authentication requests made to the customer’s identify provider (IdP). Use of this option also requires the customer to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. *Customers who choose to use the “Signed Authn Requests” option and enable signing of authentication requests on their IdP must be prepared to manage the annual public authentication certificate update process described below. The option itself offers only marginal security benefit so customers should decide for themselves if that marginal security benefit is worth the effort required to coordinate and execute the update of the certificate and potentially incur several minutes or more of down time for their use of the Quickbase platform while the public authentication certificate on their IdP may not match the certificate used on the Quickbase platform. The “Signed Authn Requests” option is only visible to Quickbase staff and can only be changed by Quickbase staff. It should only be enabled when a customer informs Quickbase of the customer's intention to configure their IdP to require signing of authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If a customer wants to know if they are using the “Signed Authn Requests” option, or would like the option enabled or disabled, they can open a support case with Quickbase Technical Support. In order to validate that the signed authentication requests actually come from Quickbase, we provide the customer with a public authentication certificate. Customers using the “Signed Authn Requests” option must ensure their IdP is configured with the public authentication certificate currently being used by the Quickbase platform to sign authentication requests made by the Quickbase platform to the customer's IdP as part of the SAML authentication process. If the public authentication certificate configured in the customer’s IdP does not match the public authentication certificate being used by Quickbase, the customer will not be able to authenticate successfully to the Quickbase platform. *Quickbase has no ability to know if or how a customer has configured their IdP. We therefore cannot tell a customer if their IdP is requiring Quickbase to sign authentication requests and we cannot tell a customer if the public authentication certificate Quickbase is using matches the certificate the customer has configured in their IdP. Quickbase rotates the public authentication certificate every year and distributes it to applicable customers inside a certificate file via this Quickbase Community post. Quickbase determines the applicable customers based on which have the “Signed Authn Requests” option enabled in their Quickbase SAML configuration. During the period of time starting on the date that we announce our intention to update the certificate, and ending after the date/time we actually update the certificate on the Quickbase platform, we make both the current and new certificates available in this Community post. After we update the certificate on the Quickbase platform, we then remove the now out-of-date certificate from this Community post. Prior to the annual public authentication certificate rotation period, Quickbase will communicate via in-product messaging and possibly also e-mail to Quickbase realm and account administrators at the applicable customers the specific date/time on which we intend to update the certificate on the Quickbase platform. When Quickbase updates the certificate, we do so during a 15 minute maintenance period on the announced date/time. We strive to provide customers with enough notice of this maintenance period for them to notify their responsible staff, typically their IT department or whichever group within the customer’s organization is responsible for administering their identify provider (IdP) system. The customer’s IdP administrator should plan to update the public authentication certificate provided by Quickbase during the 15 minute maintenance period announced by Quickbase. Doing so will minimize the chance of the customer experiencing any interruption of their use of the Quickbase platform. PLEASE NOTE: For any customer using the “Signed Authn Requests” option, i.e., requiring signing of authentication requests made by the Quickbase platform to the customer's IdP, any time the public authentication certificate used by Quickbase does not match the public authentication certificate configured in the customer's IdP, logins to the Quickbase platform will fail. It is therefore essential that the customer update the public authentication certificate in their IdP during the 15 minute maintenance period announced by Quickbase annually. Quickbase Public Authentication Certificate Rotation Maintenance Window Quickbase plans to update the public authentication certificate on Wednesday, November 20, 2024, between 8:00 PM and 8:15 PM Eastern US Time. Current and New Public Authentication Certificates The NEW public authentication certificate is provided below for you to download and install on your identify provider during the 15 minute maintenance period. The zip file contains both the metadata (with certificate contained inside) as well as the certificate on its own. Current Certificate (Expires November 24, 2024): QB_SAML_Exp11-24-2024.zip NEW Certificate: (Expires November 25, 2025): QB_SAML_Exp11-25-2025.zip Additional Information on SAML Public Authentication Certificate Configuration Scenarios and Expected Outcomes This section describes several scenarios that could exist specific to a Quickbase customer using SAML authentication for access to the Quickbase platform. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform will work normally assuming there are no other SAML configuration issues. There is no use of public certificates in this scenario. Quickbase SAML configuration option “Signed Authn Requests” is disabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed and Quickbase is not signing them because the “Signed Authn Requests” option is disabled. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has the currently applicable public authentication certificate from Quickbase installed in their IdP. In this case, logins to the Quickbase platform will work normally because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the currently applicable public authentication certificate and Quickbase is signing them with that same public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer configures their IdP to require signing of SAML authentication requests, and has a public authentication certificate installed in their IdP that is either expired, or does not match the public authentication certificate currently being used by Quickbase. In this case, logins to the Quickbase platform will fail because the Customer's IdP is expecting authentication requests from Quickbase to the IdP to be signed using the public authentication certificate they have configured in their IdP and Quickbase is signing them with a different public authentication certificate. Quickbase SAML configuration option “Signed Authn Requests” is enabled, and Customer does not configure their IdP to require signing of SAML authentication requests. In this case, logins to the Quickbase platform may or may not work normally depending on the IdP and how it handles a signed request. Quickbase cannot anticipate how different IdPs may handle this scenario. The solution is to open a case with Quickbase Technical Support and request that the “Signed Authn Requests” option be disabled.
Formula URL button - save and redirect
Hi there I?ve created a form accessible to ?everyone on the internet? for our clients to submit service requests. I added ?&ifv=20? to the url to hide the qb branding. However, doing this causes the save button to become hidden. I created a formula url button that will save it using this javascript I found on the forum: var text URL = "javascript:void(DoSaveAdd())";var Text Image = "<a id='saveButton' class='Vibrant Success' onclick='DoSaveAdd()' href='#'>Submit</a>";"<b href =" & $URL &">" & $Image & "</b>" My problem now is how do I get the page to redirect after the form is saved. Here?s a link to the form, you can try it and see what happens. https://sparkav.quickbase.com/db/bnzwm7ykp?a=nwr&ifv=20 I'd like it to redirect to an external webpage. If that is not natively possible than I'd like it to redirect to a rich text page I've created in quickbase. Any help with this would be greatly appreciated! Thanks, Elisha
Finding Duplicates in Quickbase Just Got a Whole Lot Easier
Quickbase is truly an amazing platform, and I am excited to say it just keeps getting better. I currently work as a Solutions Consultant with Quickbase and have been here for three years. During this time, I cannot tell you how many requests I’ve received where customers or prospects inquired about methods to find duplicate values. This request frequently comes up when tracking contacts in a CRM, but I have also heard use cases around transaction/expense tracking or even consolidating overlapping information into Quickbase from multiple systems. There was just not a great solution. In some cases we could force some duplicates to be visible, but the setup was a bit inelegant. Simplicity is always something we strive for at Quickbase, and so that is why I am super excited to announce (in case you haven’t already heard), that finding duplicates in Quickbase just got a whole lot easier! Let’s talk about the solution…*drum roll*… Formula Queries! If you missed the Empower Session on Formula Queries, you can find it here. Formula Queries are pretty darn awesome. If you are an intermediate to advanced builder in Quickbase, you have probably written your fair share of formulas. Traditional formulas (outside of lookups and summaries) look at only the record they are on. In other words, traditional formulas cannot look at other records in the same or other tables, only the single record on which they live. Formula Queries, on the other hand, can look at the record they live on, plus any other record in the same table, and even any other record in the same application. There are numerous uses for Formula Queries, many of which we have not yet discovered. A few uses are things like resource allocation, rolling summaries, holiday planning for project durations, and of course, duplicate tracking. So, let’s dive into duplicate tracking. Some of the items you probably should think of before trying to write the query are things like: What makes another record a duplicate? In the case of a contact, is it the first and last name that indicates a match, or in a transaction is it the dollar amount and date? This is something to really begin thinking about to ensure you are telling the system how to properly identify the duplicates. How do I want to be notified of a duplicate? Is it a report on a dashboard that displays them? Or should you receive an email if a record was saved and it’s a potential duplicate? Should duplicates exist at all? Should users be able to enter duplicates to begin with? Who should manage duplicates if found? Should it be a single person or team? Should there be some approval process? Let’s take a look at a Formula Query in action: Reading from the inside out: First, GetRecords: inside of this function is the Quickbase Query Language (see more about queries here) that compares the field id 7 of the current record (which is the Last Name) with the [Last Name] field of other records in the same table. The field id 8 is similar, but instead compares the email addresses. This specifically says get any record where the Last Name and Email of another record are the same as the record we are currently on. So, if I have two or more records where the Last Name is Stewart and the Email is JimmyStewart@example.com, then all records with that matching criteria will return as a result to that function. Then, GetFieldValues: Once GetRecords returns any matches it found that have the same Last Name and Email as the current record, then GetFieldValues grabs the contents of the returned records. In this case, the values that are grabbed are the contents of field 3 (the record ID of the match) The result is magic: Ta-da! You can see the record IDs of any duplicates (in our case where the Last Name and Email match), show up right here in this field. This may spark some additional thoughts such as “who should be responsible to see the duplicates”, or “what should we do if we identify duplicates”; There is no ‘right’ answer. You may wish to have an individual or team dedicated to managing this process, and perhaps they are the only ones with access to view these fields. Once the duplicate is identified, maybe there should be some sort of approval process to delete the finding, or some way to hide that record from end users. These are only some ideas on how to manage the duplicates, but from organization to organization or team to team, these processes may differ. And of course, the beauty of Quickbase is that you can customize this workflow to best fit your needs. Great, you have now seen how to track duplicates in Quickbase with Formula Query magic. Shoutout to our product team who keep pushing the limits of Quickbase!Cross-Table Report Formulas
I am using QB in our manufacturing facility and am trying to get an order-by-order bill of materials. Specifically, I have a table for "Raw Goods" (the raw materials we make into parts), "Parts" (the things we sell), "Assigned Goods" (an intermediate table creating a many-to-many relationship between Raw Goods and Parts), and an "Orders" table (where individual orders for parts are entered). Each part record has a bill of materials that specifics how many pounds of of each raw good is needed to make one part. When I enter an order in the Orders table and enter the quantity of parts ordered, I need the Order record to multiply the quantity of each raw good by the number of parts ordered. I can figure out how to the get the original bill of materials to show up on the Order record (by looking up the embedded bill of materials report from the related Part record), but how do I then multiply the quantity of parts ordered in the Order record by the individual raw good quantities? In the example below, I would need a column multiplying each value by 15,000. Any suggestions are much appreciated! ------------------------------ Kiel Berry ------------------------------
How we built Quickbase to scale and you can too!
Quickbase is an immensely powerful platform. At the core, we have built a custom database that combines the traditional database and application layers. Quickbase App Builders do not need to be database administrators or have coding backgrounds and we abstract out unnecessarily-complicated elements such as indexing. This leads to quicker time-to-value and the ability to build enterprise-grade ecosystems in a fraction of the time you might expect. However, no platform is perfect, and they all have tradeoffs. In software, there are three fundamental components that can be optimized for, and a fourth that impacts scale: Size: How big the database and application will get. Think number of records, tables and fields. Complexity: How much "thinking" the application does. Things like reporting, calculations, workflows, etc. Speed: How fast can the application return an answer that requires computation? Concurrency: At any given time, how many requests hit the system at the same time? This generally surfaces itself in the number of users but might also be frequency of hits from integrations. If we look at something like Amazon S3, they clearly optimize for size and speed. But, S3 is not complex (the name contains Simple). This is an intentional design decision from Amazon as to what their goal is with the product. It is generally very difficult, if not impossible, to optimize for all three since "optimization" implies some specificity and decision making. In our case, we optimize for speed and complexity. What that means is that we want builders to be able to pose very difficult questions to Quickbase by way of formulas, permissions, lookups and summaries and have Quickbase answer them ridiculously fast. Here is a Community post with an in-depth sample. That leaves "Size" on the table, which we do not optimize for. But let's define what that really means. Quickbase currently has a production table size limit of 500mb. That is a lot of data. Opening a 500MB CSV file in Excel might not go so well. For a comparison, let's say the average Kindle book is ~2.5mb and ~295 pages. That means a single Quickbase table can hold the equivalent of about 60,000 pages of text. Now, how we perform at those sizes depends on the other factors of complexity and concurrency. But in general, Quickbase applications are super-fast. Remember though that the 500MB of data could translate into much more RAM, which is where we do all our calculations that is how we optimize for speed and complexity. It is perfectly acceptable for applications to have gigabytes of memory in a single table. To give an analogy, you can buy a high-end computer today and it will probably come with a 1TB hard drive (i.e., data warehouse), but likely only 16-32GB of RAM. You can load up that hard drive with pictures, videos, and other content from the dawn of time, but how often is it used? And loading things from the hard drive takes a few seconds. Your RAM, which is much faster, keeps less information running but can work with that information orders of magnitude faster. Would you rather have Microsoft Outlook open where you can recall it in a fraction of a second, or open it fresh from your hard drive where it will take longer? The way we often define this is "operational data". Think of it as the data being used to run the business on a regular basis. In an inventory and ordering system, you obviously need to have historical ordering data to predict future needs, but you might not need every single field for every single inventory transaction for ten years in a single table - this is normally the job of a data warehouse. None of these limits prevent Quickbase from solving organizational requirements when apps get a bit large. That is when we start to discuss scale strategies. In software and infrastructure, you can either Scale Out or Scale Up. A visual of what that looks like is below. If we think about it like traffic on a highway, Scaling Up would be increasing the speed limit, or getting a faster car. Scaling Out would be adding more lanes to the highway. Scaling Out is not only how we scale our infrastructure, but how our customers can best scale their ecosystems built on the platform. As we grow, we add servers in our datacenters vs. making each server faster. When an application is created on Quick Base, our load balancers go out and determine the best place for that application amongst our vast hardware and thousands of virtual environments. What is great about this is that you, as the customer, get the benefit of spreading your applications out over virtually infinite compute resources without lifting a finger. It all happens transparently to the builder. Quickbase is in a unique position in this new "low code"/"no code" space. In fact, we were recently recognized by Gartner as a February 2019 Peer Insights Customers Choice for Enterprise High Productivity Application Platform as a Service (hpaPaaS). That is quite a name, but what it really means is that based on our stellar reviews, we are at the intersection of scalable enterprise applications and no-code building the only true no-code hpaPaaS identified. At one end of the spectrum, there are platforms such as Outsystems or Appian that are geared towards making the lives of a software engineer easier. Applications built on these platforms will take much longer to achieve value since they still require coding but might be able to get "bigger" with proper indexing, performance optimizations and many other highly-technical considerations that we do not want our builders thinking about. In general, Quickbase can still answer more complex questions, faster, due to our unique database. On the other end, we really like what Airtable has done. We find that they have a capable set of entry-level features wrapped up in a nice interface that is very appealing for someone trying to upgrade from a spreadsheet. However, Airtable has a limit of 50,000 records for the entire application on their Pro subscription. In the middle, is a more focused solution like Salesforce. Salesforce somewhat forces simplicity via the ways of limits - a lot of them. They have made the conscious decision to allow for more vertical growth at the expense of customization, and by having so many limits that they can constrain the use cases into a very tight box. And these limits are highly technical not suited for no-code solutions. Quickbase applications take infinite shape and can have millions of records in a table, let alone across an entire application. That is why we know we are uniquely positioned to solve many challenges an organization will have on their operational data without builders having a computer-science background. In fact, we co-exist with these other platforms regularly and think they have a great place in the suite of tools for an enterprise. How does this translate into making good architecture decisions during your evolution with Quickbase? If you have 1,000 employees in your company that is planning to run the entire business on Quickbase, we want to set you up for success. The ideal way to do this is by setting up logical distinctions between applications. This might mean: One billing application which is very complex due to calculations of invoicing, prorating, etc. It might only be used by Accounting, so maybe 50 people. This application probably isn't very big. One application may be used for inventory purposes which isn't terribly complex, but probably big. Inventory tracking tends to have a ledger structure which requires a million or more records. It also might have relatively high concurrency if there are frequent debits/credits. Another example could be the general Human Resources Information System (HRIS). While this app might only have moderate complexity, all 1,000 users will have access but not frequently interact with it (low concurrency). We can see from the above that Quickbase is going to cover a wide breadth of functions in this company, which is awesome! If we built all these functions inside a single application, we would then be combining complexity, size, and concurrency. And things might work out fine, but a far more scalable approach would be to spread this out over multiple applications. This not only makes management easier because a builder can administer billing without being exposed to inventory, but it also spreads all the requirements over more Quickbase horsepower. In these cases, it is critical to have a central data management (CDM) strategy. We provide many different tools for this, and it is important to select the right one. You can find an article written by our Best Practices group here. We encourage you to reach out to our Technical Support team, or your account team here at Quickbase if you'd like to discuss how Quickbase can scale with your organization. Keep an eye out for sessions and content that expand on these topics at Empower 2019.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
