BreeMackey
Quickbase Staff
Joined 6 years ago
User Profile
User Widgets
Contributions
Service Accounts and YOU!
Service Accounts and YOU! These days you may hear a lot about 'service accounts' out in the world. They are ubiquitous among databases and SaaS systems alike. But what exactly IS a service account...and how does it differ from a normal user account? Why would you want to use one? In the Quickbase universe, a service account doesn't differ from a user account except for in their intended/practical use. A service account must be tied to a real email address, just like a normal user, and provisioned just as any regular user would be. However, service accounts are generally used to drive system processes like API calls. Specifically, for Quickbase, they can be very helpful for Pipelines! If you've never had to transition an app from one admin to the next...consider yourself lucky! Service accounts can help streamline shifts in ownership to make things easier on everyone. When I was a Quickbase client - our realm grew organically in the initial years. Lots of builders who all owned different things from apps to email notifications. But as we grew as a company, we quickly realized we needed to apply some future-proofing governance in the event key people moved on to other opportunities. Our first order of business was: how would we manage a service account? Who would have access to the credentials? How would we monitor how this account was utilized? We began with laying the ground rules for our service account: 4 people would have access to the credentials: CTO (they were not a Quickbase builder) VP of Business Systems (they were not a Quickbase builder) Manager of Business Systems (overall owner of Quickbase at the company) Most senior CRM Administrator (one of the main Quickbase builders) This service account would be the owner of any and all applications in the realm. It would also be one of our Quickbase Super User accounts in the case for whatever reason ownership of an application was not transferred. This service account would be used for any Quickbase - to - Quickbase integrations. Automations Webhooks Server-side scripting (Were I still employed there, we would also use it to build pipelines.) If any of the 4 people with access left the company, the password and any usertokens they had access to would be changed within 24hrs of their departure. Anyone accessing a Quickbase application through the UI with the service account credentials would log that action in a specified table. This was cross-referenced with audit logs as a SOC II audit control to prove access. Any access had to be tied to an active work request ticket in our system. Any integration work would need to be requested via the ticketing system, and performed by one of the builders with access to service account credentials. These rules were documented as part of our larger governance documents and stored in a central location. You may be thinking 'that's a lot of rules'. The good news is that this post is not intended to be prescriptive as much as it is to clear the cloud of uncertainty around service accounts and their use. Our implementation was based on many different deciding factors: risk management, compliance with security controls, and any number of other considerations. That being said, your mileage may vary. Governance of service accounts may already be defined by your IT department. Good communication between security-managing departments is key! Interested in more? Our Customer Success team regularly partners with Quickbase clients to help distinguish which governance path is right for them. Talk to your account team for more information!Re: Demo app on Exchange: Pipelines - Create X Children
Hi @L S! It looks like your realm and token are entered correctly. Have you checked to ensure that token has access to the App/table you're making the call against? A great way to check your API call is by making the call directly in the API Portal itself. Just enter the info in the right-hand tray. (you'll need to hard-code a payload, following the examples in the API guide) If you still have issues - find me on the Quickbase Community slack @Bree Mackey or mention me here! BKM ------------------------------ Bree Mackey Solutions Architect Quick Base, Inc. ------------------------------EOTI. But Make it Safe!
EOTI. But Make it Safe! Everyone on the Internet. This phrase can elicit so many emotions. For many of our clients, they get the feeling of relief. ‘Finally! A way that we can allow OUR clients to access Quickbase directly for order entry!’ For me, a developer who was highly involved in SOC auditing processes at my last company, it leaves me with a deep sense of unease. There’s obviously an appetite for allowing EOTI! There are many use-cases where it’s considered necessary. But it’s not without risks. One of your company’s most precious commodities is its data. You don’t want your clients stumbling across another client’s data, or data they should not be accessing. One of my first forays into the world of EOTI was when I was charged with coming up with a solution to allow external applicants to submit their resume to our HR department. Obviously HR had their own Quickbase application for managing the interview process and transitioning applicants into employees. It was absolutely out of the question to open our HR application to everyone on the internet. ‘But you can control it, right?’ Yes! You can absolutely control what the EOTI role sees in your application. My concerns ran deeper. If we were to add a new table in the HR application, and bring over sensitive information from employee records…the table would default to ‘VISIBLE’ for all roles. While I knew that, other builders may not, they may inadvertently expose data and cause a public embarrassment for the company. But removing the threat (EOTI) was not an option since it was the very thing I needed to make this work! My solution? I created a new application. This application would consume data, but not store it. Back in those days, we didn’t have awesome stuff like Pipelines, so it was straight API. But these days Quickbase has made it even easier to pull off this pattern. I created some formula fields that would build URLs for my HR team to use in their job postings. These URLs pre-filled some hidden fields such as where the applicant saw the listing (Indeed, Monster, etc), as well as the actual position they were applying for. EOTI role has ADD RECORD permissions only, they cannot view records.* Applicant clicks the link and is brought to a new record in the ‘capstone’ application. They fill out their information and submit. Pipeline is triggered to read the record, create a new record containing the data in the actual HR application, and then return to the original record and delete it out of the app. This ensures that sensitive data is never actually exposed to EOTI. Since the intake app is not used for any other purpose, we don’t have to worry about obsessively checking the EOTI role when new tables or fields are introduced to ensure it doesn’t get access! Since the EOTI role only has access to add, the deletion of records could also be a nightly scheduled Pipeline depending on the activity and concurrency expected in the application. *This pattern obviously does not allow for applicants to save their application and finish it later. There is not a 100% secure recommended pattern for allowing EOTI users to find and edit records.Are you using the ToUser Function?? You Need to Read This!
Are you using the ToUser Function?? You Need to Read This! We here at Quickbase are always working behind the scenes to improve application performance. We scrutinize reports, fields, logs, basically anything we can to try to help you get the most out of the platform. Like many Builders, you may be utilizing the ToUser function to convert an email address field to a 'user' value. You may be using it in formulas or permissions. After optimizations we’ve made, and working with many of you, we are now able to clearly describe a more efficient way of building these patterns. TL;DR: Anywhere you're using the pattern of ToUser([Email]), you can exchange with UserToEmail(User())!! Let's say you have a numeric formula field where you want to ascertain if the current user matches up to an email field. Initially you might have built it like this: I don't want to go down the rabbit hole of what this means on the back end because let's face it, at the end of the day, you just want your app to work. And you want it to work wicked fast. To that end, we've identified that the UserToEmail function is a much more efficient way to go. In short, this formula only needs to make one call to convert User() to email, while the ToUser pattern has to parse through the entire user list to convert ToUser([Email]) for each record. Your new and more efficient formula would now look like this: One of the most popular patterns leverages the User() function and the User field type to control permissions. It is also very powerful because the platform is using the operational data to help drive what is viewable and editable for each user. For example, say you have a project management app and you only want the assigned project manager to be able to edit project information for the projects she is assigned to. An app builder can create a ‘Assigned Project Manager’ field using the user field type. Then in the permissions for project managers she would update the Modify permission to ‘when user is Assigned Project Manager’ as illustrated below. In the case above we only used the User field to determine which Projects are editable for a given Project Manager. Iterating on the above example, imagine you had a team of people who should be able to view projects, but only if they are on the team assigned to a project. (The general pattern for this example is in the relationship diagram at the end of this post.) It consists or 3 tables (Projects, Teams and Team Members). Now, this is where the power of Quickbase really shows itself. We use a formula field to determine if the email address of the current user viewing the data is equal to the email address on any of the Team Member records. If the email addresses are equal, the formula returns 1 (true) otherwise 0 (false). Take a look at the below screen shot of the Team Members table, and you’ll see [email protected] under the ‘Is Current User’ field display as 1 -- and all the other Team Members as 0, because he is the current logged-in user. Now the ‘Is Current User’ field from the Team Members table can be summarized up to the Teams table to the field ‘Current User on Team’. Notice that [email protected], in the above Team Member table screenshot is on the Banking team. In the below screen shot of the Teams table, the Banking team has a value of 1 under ‘Current User on Team’ because the current logged-in user: [email protected], is assigned to the Banking team. Now the ‘Current User on Team’ field can be a lookup field down on the Projects table. In the below screenshot you’ll see all Projects with the Team of Banking have a 1 under ‘Current User on Team’. This is because the logged-in user is [email protected], who is on the Banking team. The ‘Current User on Team’ field is calculated every time a report or form is displayed with the field on it, which is definitely the value of our engine, because now the builder can leverage the value to: Filter a report to only show Projects where ‘Current User on Team’ is equal to 1. Thus, creating one report which will dynamically display Projects based on the team(s) the viewing user is assigned to, instead of multiple reports filtered by team. Use the value in a custom permission so Team Members can only see Projects where their team is assigned. See the below screenshot of the permission configuration. Full illustration of this pattern and the relationships, summary fields, and lookup fields needed is diagrammed below: VOILÀ!! Anywhere you're using the pattern of ToUser([Email]), you can exchange with UserToEmail(User()=[Email])!!Quickbase, Pipelines, and SharePoint Lists
Quickbase, Pipelines, and SharePoint Lists You may find yourself at times needing to share data out to non-Quickbase users within your organization. Maybe there’s an application with country travel advisories that automatically updates itself, and your co-workers who travel could benefit from seeing these. But Quickbase hasn’t been introduced in their department yet, so how do we get them this valuable information? Enter Pipelines and SharePoint Lists! TL;DR – If you want to skip to the good stuff, download the Pipelines – SharePoint Lists application from the App Exchange to either import the YAML or follow the step-by-step instructions located in the Documents table. You may have seen my demo in the Exchange called Pipelines – Jinja JSON Object Import. In that demo you’re walked through how to import and update country Travel Advisories into Quickbase from an external API source. This demo builds on that use case, as we now want to move that information in a SharePoint List to share with our teams. I started by creating my list in SharePoint. While Quickbase can do this for us, it’s more efficient in this scenario to continually update the Items on the List, rather than create a new List every day. I renamed the Title column (as it’s a required field by SharePoint) to Country Name. I then created my columns for Continent, Score and Message, with their respective field types (single line of text, number, multiple lines of text). Next up, I returned to my Pipelines tab in Quickbase. I start off with searching my Travel Advisories table to return all of my records. In this scenario we’re not filtering the search as the number of countries does not fluctuate often, so the number of records returned (237) is manageable. For larger tables, you’ll want to be sure to add filter criteria rather than trying to parse thousands of records. I select the fields that I want to update in the SharePoint list: Continent, Country Name, Message, and Score. This way I’ll be able to access this data later in the Pipeline. Now we need to search our SharePoint Items. This will allow us to match them up with the records we returned in our Quickbase search. For each Item found, we’re going to update that Item in our SharePoint List. We’ll be updating the Message and the Score for those countries that already exist in our List. But what if a new country is present in our Quickbase app? We’ll want to create that Item in our List. To do this, we’ll insert a condition under Step B (not in the same branch as Step C) which directs the Pipeline what to do if Step B is empty. Under ‘Then’, we’ll create an Item in our List containing the Country Name, Message, Score and Continent. And now, you’re all set! Schedule the Pipeline to run after the Pipeline which updates the Quickbase application from the external API each day, and you’re getting information to whomever needs to see it!So You Want to Learn Pipelines!
Where do you start? Have no fear, the Quickbase team is here for you. We’re working hard to get you the resources you need to get started with Pipelines. Read on for all the places you can currently find them! The App Exchange Our recommendation is that you utilize your Builder account for your Pipelines training. This way you’re learning in a controlled environment and not cluttering your company realm with training applications. If you don’t have one, what are you waiting for?? They’re free!! You may not have noticed, but we’ve added a new category to the App Exchange. Can you guess what it is?? You’ve got it, it’s Pipelines. If you click on this category, you’ll find some sample applications from the Quickbase team. The Pipelines Demo alone covers FIVE different Pipelines/use-cases! QSP Summit Demo 2021 - Replace TTI – Bree Mackey Facilities Sanitation Management – Bree Mackey Pipelines Demo – Bree Mackey Pipelines: Brady Oil Safety Compliance – Nathan Underwood Empower 2020 – Pipelines Copy Templates – Leanne Snoeck Pipelines – Create Unique Parents – Bree Mackey Pipelines – Jinja JSON Object Import – Bree Mackey Pipelines – SharePoint Lists – Bree Mackey Pipelines – Capture Box URLs – Bree Mackey Pipelines – Create X Children – Bree Mackey Most of these apps include step-by-step instructions on how to build the Pipeline, as well as the YAML and instructions on how to import the YAML if you’re the type to dive right in. Quickbase University If you haven’t checked in on Quickbase University in a bit, we have lessons focused on getting you started in Pipelines and growing your skills in the Data Integrations course. Quickbase Community Articles Since you’re already here, you obviously know about Quickbase community articles. Our expert builders are loving the chance to get you more information about Pipelines, check out these posts! Pipelines and Object Linking Speed up your sales process using the Salesforce Pipelines channel How to use Pipelines to email a report at a specific time of day Importing Pipeline YAML How to Use the Bucket Channel to Schedule an Archive to Box Generate template records with Pipelines Build better trend reports with Pipelines Streamline your Procurement Process using the Formstack Channel Automatically book meetings to your Outlook calendar using Pipelines Quickbase, Pipelines, and Sharepoint Lists Transforming Data with the new API and Pipelines Send SMS Messages with Pipelines and Twilio Empower Presentations Empower 2020 was a new world for all of us. Our amazing events team was able to convert us to a virtual event that honestly, I thought was pretty amazing. Best of all, I think the session recordings were their best ever this year! Below you’ll find some quick hits, as well as regular sessions for all your Pipelines needs from the Quickbase YouTube Channel Basic Pipelines Navigation and Anatomy Authenticating Pipelines to Quick Base Building Your First Pipeline, Part 1 Building Your First Pipeline, Part 2 Integrating Your Ecosystem with Pipelines Creating a Distributed Ecosystem with Pipelines Pipelines: Admin Enablement Trending Quick Base Data with Pipelines and the RESTful API Export a CSV from Quick Base to Box Extend Quick Base Workflows to Your On-Premise Data Document Management with Pipelines Pipelines Built-In Channels Intro to Pipelines Integration Toolbox Quickbase Help The Quickbase team is working on updating the online help you know and love. Check out the Pipelines section!Importing Pipeline YAML
In this article we'll explore importing YAML from one user's Pipeline to yours. These instructions assume the following: You have a basic understanding of how Quickbase works, including how to find the DBID of a table. You have access to a Quickbase realm, with create application permissions, or someone has created the application and tables you'll need for this Pipeline. — If you will not be running it on its original application. You know how to create and utilize Quickbase User Tokens and have one assigned to the application from step 2. You have access to Pipelines within your realm, and permissions to utilize them. You have YAML created by another user, or under a different User Token. Importing the YAML Grab the YAML of the Pipeline you're importing. You can do this by clicking the three dots to the right of the Pipeline's title, and selecting 'Import/Export', then copying all the YAML code in the large box. Have the DBIDs of the matching tables in your application on hand. This step and step 7 assume you'll be running the Pipeline on a different application/table than the one the YAML refers to. Have your Account Slug on hand. - This Slug corresponds with your User Token. Ensure your User Token has access to the application from step 2. Click the down chevron to the right of 'Create pipeline' select 'Import pipeline'. Paste your YAML from step 1 in the box provided. The name and description will auto-populate from the YAML once you click outside that box. Find the Account Slug in the YAML and replace with yours. (See lines 9, 16, & 25 in the image below) Find the table DBIDs and replace with yours. (See lines 12, 19, & 26 in the image below) Click on 'Import as new'. Find more Pipelines How-Tos Below: Pipelines and Object Linking How to use Pipelines to email a report at a specific time of day How to Use the Bucket Channel to Schedule an Archive to Box Build better trend reports with Pipelines Generate template records with PipelinesAll the Things You Can Hide!
All the Things You Can Hide! Have you ever looked at your Quickbase implementation and thought 'I really need to drive my users to use this process, but they’re getting distracted by xyz…’ read on to find some common, and not so common things you can hide from your users at different levels. * Please note that ‘hiding’ or ‘obscuring’ things in Quickbase is NOT the same as securing them. Keep an eye out for the asterisk and red text throughout this document for clarifying statements. 1. Realm Level If you're a Full Account (realm) admin, it's a great idea to limit who can create applications. If you don't have a solid App/Builder Governance process, you could end up with a graveyard of applications where no one actually knows what their function is. 1.1 Application Creation Permissions From your 'My Apps' page --> Manage my account --> Permissions Specify who can create applications, as well as manage the account. 1.2 Additional Account Permissions From your 'My Apps' page --> Manage my account --> More --> Edit Account Properties Protect Builders from possibly sharing sensitive data by disabling the ability to share apps with Everyone on the Internet by disabling the setting at the realm level. Hide the ability for users to share an application on the QB Exchange. You may have applications where you don't want to allow the app admin to test as a user in case they could view sensitive data. 2. Application Level At the application level, we give you even more control! 2.1 Role Level Within the User Interface tab of each Role, you may want to hide the following functionalities based on your own needs: App & table settings -- By checking this box, if the Role also has 'Edit app structure and permissions' checked, they'll be able to create a new table, but not add fields or access the Settings. Users -- If your Role has 'Manage users and share the app' permissions, that will be hidden from their top ribbon, but they'll still be able to add new users through user picker fields if you allow users to create new choices. Favorites & Recent -- Check this box if you wish to hide the Star icon in the upper right which shows things users favorite, or recently visited in the application. Search -- If you have a large application, checking this box can improve performance by removing the user's ability to default search the entire app for any search term. Are your users used to using this functionality? Spend time with them documenting what they're searching for and create targeted 'ask the user' reports for them at the table level. Help -- Control which Roles can contact our Care team or search Quickbase Help pages. As these are pertaining to Quickbase as a whole, they can be confusing for new users, and many admins create their own help documentation which is specific to their application. Test as another role or user -- If a user has 'Edit app structure and permissions' checked, you can turn off their ability to test as another Role or user by checking this box. This can help control what data a user can see, for instance if you only want users to see records they own. Additionally, in the User Interface tab, you can control visibility of the following: Tables from the table bar. This is really handy for cleaning up a user's view. If your users only interact with ‘Order Items’ while on an ‘Order’ record, it may make sense to hide that table from the table bar. Add Button/Links, Import/Export Links, Save as a Spreadsheet Link, Multi-record Options, Email Buttons/Links and Print Links. This can help out if you want to control some of those functionalities and funnel your users to a different process, like using a unique button utilizing an API call to create a new record rather than using the native button. * Be advised that obscuring these items is not the same as securing them. Please see our documentation link on #9 below. You can show/hide reports for each table by clicking 'Set report access' and toggling the checkboxes. This can help streamline your user's views by not cluttering them up with extraneous reports they don't need. * Again, keep in mind if another user shares the exact report URL with a user in a Role where the report is hidden, they will be able to see it. The Permissions tab is where you can truly ‘secure’ what your users can and cannot see. Please read more on configuring permissions here. 2.2 Application Settings In your app properties page (App Settings --> App properties) you can hide the following from your users: Under Advanced Settings --> Options, hide new/updated icons that appear for records in reports. Some people just don't like them! Here you can also exclude the user picker’s ability to find users who are already in the app. For example, you may have invited people to the same app who are from competing vendor companies and you don’t want them to see those users. Under Security Options, hide the application from public searches. This is helpful if you have EOTI enabled, but don’t want it searchable by other Quickbase users. 3. Table Level At the table level (Settings --> select table from dropdown --> Advanced Settings) we give you a few more options for customizing your user’s experience: If you've opted to allow Global search, you can omit your table from it by unchecking 'Include this table in global searches' under Advanced Table Settings. If you'd like to hide a table from everyone and not just specific roles, you can uncheck 'Show in the table bar' and the table will be hidden from all roles. Or, you can obscure the actual table name by leaving the box checked and populating the 'Override the heading with' box. Best Practices advise that you stick to a naming convention for tables that best allows for indicating what data a table holds. Utilizing this feature to obscure a table name could cause more confusion, use with care. 3.1 Report Settings Get familiar with your Report Settings page to streamline your reporting by customizing your user’s views: Control who will be able to see the report in the reports & charts view. This is essentially an extension of setting report access in individual Roles (2.1.8 above). This way you won't have to go all the back to the Role page to hide a new report. Columns from the report by using 'Custom columns' to only show relevant data. Filter your records to hide those that are not necessary for the report. Keep your users from drilling into the report by removing access to the Dynamic Filters. If the report is particularly large, restrict users from utilizing the Quick Search field. (This checkbox is only visible when you select 'none' for Dynamic Filters see 3.1.4) Toggle the checkboxes to hide totals and averages which are shown by default. (This can also be controlled on the individual field’s properties page.) Icons for editing and viewing records from the report. Old or non-edited records: just toggle the 'Display only new or changed records'. 4. In Conclusion Please keep in mind, if you have sensitive data that under no circumstances certain Roles should be able to access, you should remove that access in the Role itself or the field-level settings to ensure security. A good rule of thumb is to ask yourself ‘could I be fired for sharing this data with someone?’. If so, secure it and implement a process for users to request additional permissions, and the management approvals needed for those. If you have questions regarding security, please contact our Care team or your CSM for further assistance!Do You Use Cookies in Your Quickbase Implementation?
**UPDATE** As of 4/3/20, Google has rolled back the SameSite changes: '...in light of the extraordinary global circumstances due to COVID-19, we are temporarily rolling back the enforcement of SameSite cookie labeling, starting today. While most of the web ecosystem was prepared for this change, we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time. As we roll back enforcement, organizations, users and sites should see no disruption.' They are planning to re-roll out the changes sometime this summer. You can follow the updates on the Chromium Blog. If so, you’ll want to be aware of changes coming beginning with Google Chrome v80, coming 02/04/20. Firefox currently has them available to test and will be making them default in the near future. What’s changing? As of v80, Google Chrome will change the default behavior to the SameSite attribute: Cookies without a SameSite attribute will be treated as SameSite=Lax. Cookies with SameSite=None must also specify Secure. Who uses cookies? Many developers utilize cookies to track website activity. Cookies can be used to provide personalized web pages (when you select a different ‘theme’, for example), and online shopping sites often use them to track what you have placed in your shopping cart. So why are we sharing this? Because some of our clients have need for a website front-end integration on their Quickbase realms. Our clients are continuously pushing the boundaries of what Quickbase can do, so it could be something we haven't heard of yet! You’re now probably asking ‘do I need to worry about this?’ and the answer is, if you do not have an integration with Quickbase where you have designated cookies, then it’s likely you do not. If you have utilized a QSP, be assured we’ve shared this coming change with them, but feel free to follow up with your contact there to ensure uninterrupted service. You can rest assured we’re doing our part to make sure Quickbase continues to provide a consistent experience in modern browsers. Click here for more information from the Chromium Blog. Click here for an explanation of SameSite cookies. Click here for more information on the IETF proposal for these changes. Click here for more information on defining cookies and set-cookie header fields.Re: Autofill fields in table based on a dropdown
Hi Ramya -- With the assumption that you have many clients (more than say...10), the most scalable way of doing this is having a separate Client table which houses the name, email and phone number of your clients. You would then have a relationship where Clients have many Jobs, and your users can select the Client Name from the reference field on Jobs, and then display lookup fields to that client's email and phone. If you wished, you could give your users the ability to create new Client records in case the Client does not currently exist. Other solution(s) would require you to hard-code email/phone values based on selection in the Client drop down (I'm currently assuming it's a multiple-choice field), which is not scalable or advisable. ------------------------------ Bree Mackey Solutions Architect Quick Base, Inc. ------------------------------
Groups
Women's Qrew
For builders who identify as women to connect and learn from each other.
