I have user and role not matching
I created a new role and gave a user access to test the role. She can't see two fields on the form. When I test the role as the role I can see the two fields. When I test it as the User I can not. Things I have done. Had her clear cache, reboot browser, computer. Opened up the role completely for full access no restrictions, gave her a new user with a new email address. and still the role I can see the fields but under her user name I can not. I am going live with this database next week and QB tech I don't think the rep starts until noon Est and I need help now. Wth - I have tried everything.
Auto-ordering or Auto-issuance system
I have a concept in mind and I think that Quickbase has the capabilities, but I just want to get input from others who know a lot more than I do. So, we are a travel company and we have partner companies that purchase certificates from us. Currently, we print them out with a specific code and number on each one and FedEx to partner for distribution. Recently, we have decided that we would really rather the certificates go out digitally and that is going ok. And now, I was wondering if it is possible for a partner to login to their "limited-access" portion of Quickbase and 1-enter in required info (name, email, account#) of person to receive certificate and Quickbase can then generate and email certificate and/or 2-partner logs in and is able to enter amount of certificates to be sent to his location. I am confident that #2 can be done, but I am curious about #1. Please share opinion, info, guidance. I can tend to overthink the obvious. Thank you, Kim Cameron
Attachment - file name
I need to rename an attachment. I want to remove all blank spaces and replace them with underscores. I found a post from 3 years ago that asked the same question. There was no inherent solution at the time. In a pipeline, I can upload the file to Sharepoint and add text to the front or end of the name, but I can't inherently adjust the original name. In the below example, I am adding a string of characters to the beginning of the name but I can't figure out how to adjust the 'File name' property of the Attachment type. Any suggestions on how to change the the 'File Name' attribute prior to calling a pipeline (i.e., formula-text field) or within a pipeline will be appreciated. Thanks...Aaron
Quickbase Email Deliverability Solutions for Spam Filtering
Quickbase keeps an up-to-date Sender Policy Framework (SPF) record for all email servers used to send email from our platform. If you use SPF, you can adhere to your organization's spam filtering policy without having to allowlist the IP addresses of approved senders. Quickbase also maintains a valid DKIM signature. Important:SPF is our recommended and supported method for spam filtering. Since the IP address ranges of email servers can change without notice, customers should NOT allowlist IP addresses as the primary method of spam filtering to allow Quickbase emails to be received via IP address. See http://en.wikipedia.org/wiki/Sender_Policy_Frameworkfor more information on SPF. If your organization does allowlist email IP addresses, you should plan to implement SPF as soon as possible. If you continue to experience deliverability issues, despite implementing SPF, then allowlisting may be required to bypass more stringent filtering for some configurations. We recommend the allowlisting of the notify@quickbase.com email address as the first step in troubleshooting deliverability issues. If notifications continue to be unreliable, after allowlisting the notify@quickbase.com address, we would then advise the allowlisting of the Quickbase Email IPs listed in this article. If you choose to allowlist IP addresses, here is the CURRENT range used by the Quickbase Platform: 156.70.3.202 156.70.3.203 156.70.3.204 156.70.3.205 156.70.3.206 156.70.3.207 156.70.3.208 199.15.225.10 199.15.225.8 199.15.225.9 If, after all the steps above, you still continue to see deliverability issues, you could also allowlist*@quickbase.com, although this would not be the recommended course of action.
Test As Role URLs?
I have an app where I rely heavily on roles and role permissions to view certain data and forms. Because of this I need to test as a role when developing new roles to ensure the users cant access other roles data. Is there a way to get these "test as role XXX" as a callable URL I can map to a button on the admin dashboard? I want to use the custom branding setting in the app to hide the Quickbase standard menu options for all users so they can't try and get to the My Apps page in our realm. Is the custom URL to test as a role possible?
Timezones Outside of US - Based on Location/Address
Is there a way to set up a way to calculate the time based upon the address inputted. There is a process in place that calculates time for locations INSIDE the United States. Is there a way to do this outside the US, besides hardcoding each location?Resolving QuickBooks Error 1903 During Installation
I'm encountering QuickBooks Error 1903 during the installation process. This error message indicates an internal issue that prevents QuickBooks from installing correctly. What steps can I take to resolve this issue? Any detailed guidance would be greatly appreciated!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 to download the zip. 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.
