Manufacturing Qrew
A Qrew focused on Manufacturing use cases and solutions.
New Admin Qrew
Best place to learn ways to Admin an App or an Account in Quickbase
Links Banner
Main Content
Recent Content
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!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 sgalloway@quickbase.com 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 sgalloway@quickbase.com, 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: sgalloway@quickbase.com, 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 sgalloway@quickbase.com, 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])!!
American Airlines SMS Conference
Team, Thanks for being a part of the Aviation Qrew and for attending last week. We're off to a great start and excited about what lies ahead for this group. One of my colleagues saw this and thought we would share. This SMS conference is hosted by American Airlines and although is sold out, there is a waitlist and you can contact Callie.choat@aa.com if you would like to be on the waitlist. Quickbase is not a sponsor, this is just a way to make the community better and share best practices. SMS Industry Forum Registration hosted by Whova Whova remove preview SMS Industry Forum Registration hosted by Whova 2024-04-09, Fort Worth, TX View this on Whova > Cheers, Gareth ------------------------------ Gareth Hughes ------------------------------
Quickbase Recertification for 2023: Automatic Recertification
Quickbase University is working on changing the way our customers maintain their certification credentials. We will move away from requiring professional development units (PDU’s) to targeted learning courses to maintain certification. Although this remains our plan, Quickbase University has made the decision to roll out these requirements beginning in 2023 for 2024 certification. As such, all 2022 certification credentials will automatically renew at the beginning of 2023. This means that all holders of Quickbase 2022 certification credentials do not need to perform anything for 2023 certification. In the coming months we will release more information about plans beginning in 2023 for recertification for calendar year 2024.
The future of Application Lifecycle Management on the Quickbase platform
We know our customers have complex problems to solve. They need a powerful and adaptive toolset to be able to adjust to the surrounding dynamic environment and to eliminate Gray Work. And this is what Quickbase does for them... However, with the level of flexibility and agility that Quickbase provides, there comes the need to oversee and manage the growth of solutions in a scalable way. There is a growing need to have safety processes in place for managing parallel streams of app and workflow development.. Most of all, customers need to ensure the business continuity of their Quickbase solutions. No matter how, when and who is developing anything, the business processes keep running and never get interrupted or distorted by the constantly ongoing change management processes. These needs have been well-known and explored in the traditional software development industry during the last few decades. There are already proven and well-established best practices. Our mission is to apply best practices from traditional software development, adapted to the needs of a business builder in Quickbase. The no-code space has not solved all the ALM challenges in a way that truly works for non-technical users. In Quickbase, we see an opportunity to define what the best-in-class ALM experience for non-technical users looks like. The main pain points we repeatedly hear from our customers are a lack of: Isolated environments, segregating the production solution from testing and development – in other words dev/test/prod Easy version control for Quickbase, with comparison of versions Promotion of changes between environments Selective publication of changes (deployments) Approval processes around deployments Fine-grained auditing of all deployed changes To respond to these market needs, we are developing a new API-based framework that enables builders to partner closely with their IT department to satisfy even the most complicated lifecycle needs. How do we plan to solve those problems? We are developing a framework, called Solution APIs and a new way to represent the Quickbase schema you are building – QBL (Quickbase specific language). With this framework, we will provide several CRUD (create, read, update, delete) APIs that enable a very high level of flexibility and adjustability to fit any organization's needs. You can see more details about Solutions and related features for example Versioning and Rollback here: https://www.quickbase.com/blog/scaled-solution-management About QBL QBL, short for Quickbase Language, is a new way to describe the schema of your Quickbase solutions. Everything you can configure in your apps and pipelines can be represented using natural language. One way to think about it is like a map of your Quickbase solutions – there you can see everything – tables, all their fields, the structure of forms, reports, dashboards, relationships, roles, the structure of a pipeline and all the settings about those items. Here is an example of QBL: In this example we can see a few rows of the description of an app that is called “Service Request Production”. You can see the description of the app, the color, the app icon, the set currency, first day of the year etc. If you have built Quickbase apps, you recognize those to be your app settings. Here is a similar example for a field, where you can recognize the field type, label and the configurations available for a field type DateTime: At this point you might be wondering how all of this is applicable to you. We believe that the QBL and the Solution APIs are so flexible that they can be used in many use cases. A key opportunity we see is the option to integrate Solution APIs with any code Source Control Management (SCM) toolset you have in your organization. SCMs are specifically designed to manage code formats and have a vast array of features to support version control, separated parallel development, role management and so much more. By using Solution APIs with SCMs, you can tap into those capabilities. Some examples of SCM tools are Git, Azure DevOps, Helix and others. Learn more about SCM - https://www.turing.com/blog/source-code-management-tools-best-practices/ Real-world applications Business builders can partner with IT teams to leverage this technology to more deeply integrate Quickbase within an org's stack. But that certainly isn't a requirement. While we know the Quickbase community is going to come up with use cases we could never imagine, there are two fundamental ways customers can consume these new APIs. First, using your company source control tools. Second, running Quickbase on Quickbase. Here are just a handful of the examples we know you’ll take advantage of: SCM: Version control You will be able to take advantage of capabilities inbuilt in SCM tools to seamlessly keep a log of every single version deployed – this is what source control tools are designed for. SCM: Compare Versions (DIFF) QBL is built to enable you to compare versions of your Solutions to the smallest detail. SCM tools are very good at highlighting these differences. Run "Quickbase on Quickbase”: Dev/Test/Prod - create environments With Solution APIs you can unlock a lot of power by creating multiple versions of your Solutions and assign them to be your production, staging, testing and development environments. This can happen by using a sequence of: Export QBL of a Solution -> Use Create API with the exported QBL to create a copy solution and assign it for an environment. Or you can tap into the flexibility Quickbase offers and manage your APIs and environments with a Quickbase app and Pipelines. The app and pipeline can work together to facilitate the creation of separate environments – the app is the “frontend” where you make the configuration, and a pipeline executes the APIs on the background based on triggers in the app. Run “Quickbase on Quickbase”: Dev/Test/Prod - deployments across environments Another way you can take advantage of a Quickbase managed set up is to also control the deployments of changes across environments. In an app you can set rules about the directions of deployments (so you eliminate the option to deploy from test directly to prod for example) as well as permissions for users that are allowed or not allowed to execute deployments and even approval steps. And this is only the beginning. Here are some other things we heard from builders like you: A use case we call “build once, deploy everywhere”. If you need to re-deploy the same Solution several times – for example for different local units of your business or even for different customers, Solution APIs will give you the perfect opportunity to instantly replicate the template Solution in the same or a different realm make updates with new developments or fixes in seconds - to all destination Solutions. Something obvious, but it might be important for your organization – mapping and documenting the Quickbase structures and relationships, including internal and external pipelines. We know for some of our customers this is very important. While Solution APIs are still under development, we are aiming at releasing a limited schema coverage version focused on tables and fields only in early 2024. The first release will enable you to export, import and update your applications properties, your table settings, all field configurations and roles as well as roles permissions over fields and tables. After that we will continue enhancing the coverage of the APIs with forms, reports, dashboards, pipelines and all other Quickbase schema. We hope you get inspired to think about how you can apply these new tools in your organization and don’t hesitate to contact us with any questions or feedback you have. We would love to hear back from you. If you are interested in early access opportunities, more information on the topic or want to share your feedback with us, please don’t hesitate to contact your Quickbase account team or myself at rstoycheva@quickbase.com – Leave feedback for us here !All 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!The magic of Service Accounts
We’re so glad you’re here! Today, let’s learn about Service Accounts and how they can help teams with multiple Realm Administrators or Builders working on integrations. Service Accounts are special admin accounts that let apps connect to Quickbase and use its data without needing a specific person to log in. This is super helpful when multiple people on a team are working together on integrations because it makes it easier to see who’s doing what and simplifies collaboration. Here’s why Service Accounts are important for your team: Transparency: They give a clear view of how and when data moves in and out of your apps, so everyone knows what’s happening. Security: They help keep things secure by allowing automated tasks without sharing personal login details. Continuity: They ensure processes aren’t reliant on any one individual. This helps avoid disruption. Even if someone leaves the team, everything continues running smoothly. For step-by-step instructions on setting up Service Accounts, check out our help article: Setting up Service Accounts. Feel free to ask questions or share your experiences with Service Accounts below…and happy building!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.The sheer power of the SearchAndReplace function
The sheer power of the SearchAndReplace function One of the ways Quickbase empowers non-coders to build their own business solutions is through our Excel-like formula language. The SearchAndReplace function raises the bar by making it easier to manipulate text data. Aside from replacing all appearances of one word with another word, what is it that makes SearchAndReplace special? First, you can use SearchAndReplace to remove all appearances of a word or phrase from a piece of text. You can do this by using a pair of empty quotes. This can be useful for filtering out noise in your data. For example, some companies sync in email messages into their Quickbase apps. You could use SearchAndReplace to remove HTML tags from the body of an email message. This formula would remove all appearances of the term <p> from the Email Body field: SearchAndReplace([Email Body],"<p>","") You can also use the SearchAndReplace function several times in a row. This allows you to replace several words or phrases in the same piece of text. For example, this formula would search the Notes field. Then, it would replace those three acronyms with the phrases they represent: SearchAndReplace(SearchAndReplace(SearchAndReplace([Notes], "GTM","Go-to Market"), "KPI","Key Performance Indicator"), "YoY Growth","Year-over-Year Growth") Finally, you can use SearchAndReplace with other functions like Left and Right. Let’s say you wanted to exclude all text in a field up to the first appearance of the word “Approved”. This could help you examine an approval log and determine whether multiple approvals have been recorded. Using just the Left/Right/NotLeft/NotRight functions, this would not be possible since they only operate on a single character at a time. But what if you first replaced a word with a single character, and then use a function such as NotLeft? First, select a character which does not appear in your source field. Let’s say that # doesn’t appear anywhere in my source data. Below you’ll find a checkbox formula. This can determine whether the word Approved appears more than once: If(Contains(NotLeft(SearchAndReplace([Approval Log],"Approved","#"),"#"),"#") = false, true, false) I’ve worked at Quickbase for nine years, and this community has always impressed me with its creativity. Have you tried out SearchAndReplace yet? I’d love to hear what problems you’ve been able to overcome using this function.November Qrew Meet Up Recap
Hello Manufacturing Qrew! Thank you all who were able to attend today’s Manufacturing Qrew Meet Up. Here’s a quick recap of the meeting: Jen Clark from General Sheet Metal shared her Purchase Order App + Sage 100 Integration and Delivery Management Dashboards. She emphasized how Quickbase helped save her team money on wasted scrap and became more efficient removing duplicate data efforts across the org. They plan to add additional apps, add a mobile component with FastField and more. If you are interested in learning more about how Jen set up the Sage integration, please reach out and I’ll be happy to make an introduction! The group had a had a great conversation on the difference between Power BI and Quickbase and ways their companies handle different use cases that might need a Quickbase App vs Power Apps. Definitely worth listening to if you are evaluating the difference between these tools. Kory Hoppes, Solutions Consultant, shared how to create secure links with the audience. There are few other items he wanted to share, and we’ll be recording and sharing those as a Qrew tip in the new future. Here’s the link to the recording : https://quickbase.zoom.us/rec/share/n-JkBBzwCympU61tXLO0UImNpdpqqELptEjGaumv6Fz2ykWmJ-kk8BqMt9viaUOO.a3ggmVWC0GL6T-oN?startTime=1730912115000 FYI: No password needed to start the video Would anyone like to join the club and share your use case? Ping me and let's talk! We love and need more customer stories for our group. Thank you!
