Recent Content
Google API QR Codes not working?
Hi, has anyone else run into the issue this week where the QR generator at chart.googleapis.com has suddenly stopped working? Even my sample code of https://chart.googleapis.com/chart?chs=100x100&cht=qr&chl=HelloWorld is returning a 404 not found....1.8KViews0likes1CommentJinja 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 ------------------------------300Views2likes1CommentEmpower Discussion
Hi Everyone, Happy Empower Day!!! This thread will be monitored throughout the day by the members of our Product Management team. If you have a product specific question from content you saw today during Empower, drop the question here and we'll have a member of our team respond!217Views0likes1CommentUsing ""&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 Guide121Views9likes2CommentsSAML Public Authentication Certificate for Signed Authn Requests
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 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. Please note that 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. Please note that 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. 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 15, 2023, 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 itself. CURRENT (Expires November 25, 2023): QB_SAML_Exp11-25-2023.zip NEW (Expires November 24, 2024): QB_SAML_Exp11-24-2024.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.121Views2likes0CommentsLive Chat with Others in The Qrew in Discord
You may have missed my blog a ways back on The Discord Qrew...you can learn about ways people are helping each other out clicking the above link. If you're looking to engage in a real time chat experience, with other Quickbase professionals, the community-led Discord Qrew is a great spot to do this. Come connect with RossonLong1 and others as they tackle challenges in real time! Click here to access!114Views2likes7CommentsWhen the Expiration Date is On or Before Today, Change the Contract Status to Expired
Hello: I have a contract application. Goal: When the Contract Expiration Date field is on or before today, and the Exception to the Expiration Date Dynamic Form Rule field is unchecked, I want theContract Status field to automatically change to Expired. Question: What is the best method to accomplish the above goal, form rule, text formula, or pipeline? 1. I tried the below form rule. However,it works intermittently. I still see expired contracts that show as active 2. I created a formula - Text field named Contract Status Formula, but I am unsure whether my formula is correct. If( Today() <= [Contract Expiration Date], "Expired") 3. I tried to create apipeline. My first attempt was to Search Records/Update Record. My second attempt was to On New Event/Search Records/Update Record. However, I know I am missing a step. Any step-by-step guidance would be greatly appreciated. Thank you, RoulaSolved109Views1like12CommentsOptimizing Quickbase Admin Console Connected (Sync) Tables for Effective Governance
Approximately 5-minute read In the ever-evolving landscape of data management,Quickbase's Admin Console Connected (ACC) tables (known also as Sync tables) stand out as a pivotal tool for administrators. These tables are more than just a feature - they represent a methodology for streamlined data governance and management. This blog post delves into the strategic setup and utilization of ACC tables, guiding you through a journey of efficient administration and governance of your Quickbase realm. The Governance Starter Kit To establish a comprehensive governance framework, realm admins need to create three core applications. These three apps lay a solid foundation, which allows for easy expansion and subsequent modifications. Step 1 - Create an app called Admin Console Sync Hub: This is the centralized location for all ACC tables and is crucial for warehousing data points that the realm admin will use in the Realm Insights app. Less is more in this app. It is not advised to add relationships, reports, roles, users, etc. This is essentially a data repository that updates according to the app manager's specifications. ACC Tables currently include Users, User Access, and Applications. It is important to create this foundation to prepare for future tables that will be added. Step 2 - Create an app called Realm Insights: This is where the Realm Admin will slice and dice all realm data to get a holistic understanding of the realm and its overall health. It shows how Apps and Users are being utilized and what they interact with in the Realm. It will also help develop, enforce, and maintain policy with Quickbase and ensure alignment with your company IT (Information Technology) strategy. Step 3 - Create an app called Realm Logger: An advanced audit log that tracks specific attributes with a defined granularity. Some examples of data tracked would be App Deletions, User token Additions, User token changes, User Access additions/removals App Manager changes, etc. Through the utilization of Pipelines, this app creates logs from changes in data in the Admin Console Sync Hub app and the Realm Insights app. Although some of these attributes may be tracked in Audit Logs, this methodology allows flexibility and granularity based on the need of the client’s organizations. Admin Console Sync Hub Overview It is important to note that each ACC table should come with a Pipeline. The Pipeline has multiple purposes. It copies data from the Admin Console Sync Hub into Realm Insights. It also logs its results in Realm Logger and changes/additions/removals of the data that was interacted with. ACC Table Pipeline Process to log a Deleted App ACC Table of Applications updates once a day. When the table updates (or at a scheduled time), the Apps Pipeline fires. It updates the Realm Insights Applications Table with the updated data. The Pipeline then compares the updated data and removes all records (apps) that are no longer in the Apps Table of the Admin Console Sync Hub. These records are then added to the Realm Logger Apps Deleted Table. Now the Realm Admin can see all App deleted in the Realm and the attributes they choose to maintain. Separation for Simplification A common question is why this solution keeps the Admin Console Sync Hub and its ACC tables separate from Realm Insights. While integrating directly into Realm Insights is possible (and often necessary for certain API integrations), maintaining separate entities simplifies app management. This separation prevents the need for re-architecting Realm Insights with each new ACC table addition (read about our expansion plans below), enabling a more streamlined update process through pipelines. This method has proven easier to scale and allows the client to build the solution as they see fit. There are a wide range of building skillsets, and technically, you may not want a pipeline per ACC Table. You may want to use one pipeline or twenty. The point is to prepare for scale and keep applications limited in roles and scope so that a “Franken-App" does not occur. User Token Added as ACC after a Few Months Example: A Realm Admin imports a User Token file from Admin Console on a weekly basis in a Table labelled “User Token” in Realm Insights. In a few months, the Realm Admin has been told a new User Token ACC Table is going to be made available. There are many reports, workflows, and relationships associated with the User Token table in Realm Insights. Once the User Token ACC Table is made available, the Realm Admin can create a pipeline to copy the data into the Realm Insights app. NOTE: All Quickbase plans include audit logging, which is accessed from the Admin Console. If you decide to set up your own audit table in the Realm Logger app, this can be a great tool to facilitate custom reporting and notifications. However, any audit records saved to a Quickbase app can be modified or deleted if the roles in the app allow this. That means the Realm Logger may not meet your needs if you plan to use it for compliance purposes. To determine the right approach in that case, please make sure you consult your legal team first. Use Cases Here are some examples of some of the data insights you can gain by just leveraging the three ACC tables that exist now: Users – Users in the Realm How many non-company emails are being used in the realm Anytime a user changes permissions: Can Create Apps Realm Approved Realm Admin Super User Pipeline create permissions App Admin Can Create User Tokens Non-Realm Approved Employees Users to Deny (based on length of time not accessed) Users that have Never Accessed an app, but still have Access Access – Users and their app access # of App Access per User App Level Permissions per User per App # of Apps Accessed per specific timeframe Apps – Apps in the Realm How many applications have not been accessed in 90/180/240/360 days # of Apps per App Manager Apps Created per Year Everyone on the Internet Apps Apps with or without Vendor Access Anticipating Future Expansions Quickbase's commitment to growth is evident with the planned introduction of new Admin Console connected tables, encompassing User Tokens, Pipelines, Groups, Tables, Pipeline Access, and Solutions. These additions, expected throughout 2024, highlight the need for a robust foundation to facilitate easy scaling. Conclusion: The ACC tables are more than just a single feature. They are a cornerstone of effective Quickbase governance. By understanding and implementing these strategic practices, you can transform the way you manage your realm, laying a foundation for growth and efficiency. As more data points become available, scaling becomes much easier as you mature with the product and the product adds additional ACC Tables and APIs. Explore more about connecting ACC tables in our help center article. For in-depth information and if you need further assistance, don’t hesitate to reach out to your sales or service support contacts.100Views2likes0CommentsBringing attention to the End of Life for Webhooks
*Note, my title says End of Life, but should read End of Sale (webhooks will still work, just can't add any more). However, this posting still reads the same. Hoping to get more eyes on this blog post, and if there is enough uproar, maybe Quickbase will reconsider. The comments on the post are spot on (I would add a comment, but for the life of me cannot figure out how). In addition to the current comments, webhooks are great for very simple tasks (if a new record is created, create record in my combined table...), keeping the number of pipelines down to a manageable amount. If I had to convert my webhooks to pipelines, I would suddenly have an extra 100 pipelines, making it nearly impossible to search through. I understand that my existing webhooks will stay, but in the future who wants to search through thousands of pipelines? Let your voice be heard if you think the removal of webhooks is a terrible idea! https://community.quickbase.com/blogs/brian-cafferelli1/2024/03/15/creation-of-new-qb-actions-and-webhooks-will-be-lo ------------------------------ Mike Tamoush ------------------------------100Views11likes14Comments