Applications, especially those targeted at business users, constantly evolve. In that way, no app can ever be considered truly “complete.” New apps, even those launched within days or hours, may suddenly need to be customized or tweaked to stay relevant and map to new market, competitive, or customer dynamics.
Capabilities such as adding new fields, modifying forms and reports, or customizing dashboards are critical for application managers and, some may argue, even for end-users. These capabilities may appear harmless on the front end, but when it comes to the underlying data architecture every change can potentially alter the underlying schema of the application. Other changes, such as incorporating new use cases to serve a larger population of users, present even more complexity and further alter the performance and usability characteristics of the application.
Despite the ever-changing nature of business apps, the reality is that application developers often must design them without knowing what lies ahead. Therefore, developers typically design apps for flexibility, laying the groundwork for them to be altered throughout their lifecycle.
Low-code or no-code development platforms support this type of creation by streamlining the continuous nature of the design process while enabling business users to take on some of the development themselves to better align with their ever-changing needs. Further, these platforms are designed for resilience so that performance, scalability, and usability are retained despite the fluid nature of the database schema behind these applications.
Beyond the design of these applications lies the challenge of securing them. Developers, including the new class of non-technical “citizen developers,” must ensure that the security and governance they set in place do not fall apart when the schema of the app changes. But if you can’t foresee an application’s destiny, how can you uphold its security for use cases you have yet to encounter or anticipate?
DIY permissions, no coding
Low-code, rapid application development platforms such as Intuit QuickBase offer fine-grained security features that allow users to specify how data can be both accessed and aggregated. On such platforms, it’s not just the app development itself that is code-free. Detailed user permissions can be set in place by an administrator without any requisite knowledge of coding language, allowing users to secure access to the information they own based on functions, individual users, teams, and more. This type of functionality makes it easy to present users with only the data they need and to protect confidential data that they shouldn’t have access to.
By using QuickBase’s ability to set employees as a data table that can be manipulated and assigned relevant categories (departments, divisions, regions, etc.), application owners and administrators can control access at a granular level -- and in a scalable and secure way -- without writing custom scripts.
For an example, let’s consider a project management app for a regional sales organization. Ideally, employees should only be able to view projects in their own region, and this can be accomplished by assigning users to regional categories.
We’ll assume our project management app has a Projects table, a Tasks table, and a Resources table, which includes the resources (such as project team members) that can be assigned to tasks. We’ll also need an Employees table and a Regions table.
Employees should be a table of all the people whose access we’d like to control within our app, while Regions should be a table of all the regions within our company. When creating fields on the Employees table, we need to include two specifically built fields: A user field called Employee, where we'll record the employee’s QuickBase user name, and a region field called Region, where we’ll select the employee’s region from our Regions table.
Next, we’ll create the relationship between the Employees table and the Regions table. The key to creating an app with permissions specified by region is defining the relationship between our employees and their regional location. In this instance, one region will have many employees, not vice versa.
Once we've created the relationship, we'll add a Summary field to our Employees table. This field will be a count of employees related to the region with the matching criteria that the Employee field is the current user. Now, the region to which the user is assigned will have a value of 1 in this field, and all other regions will have a blank value. We’ll name this field Current User Count.
Here’s what the relationship between the Regions and Employees tables should look like now:
Next, we’ll put this relationship to use. For this example, we want to make sure that employees can only view projects and tasks in their own region and don’t have access to projects or tasks in any other region.
In order to properly define the relation, it’s important to specify that each region will have many projects, not vice versa. And we'll make sure to look up that Current User Count field we created so it will become part of the data for each project record.
With all that set up, we can now start to alter the permissions for the Team Member role. By default, team members can view all projects and tasks. So we’ll start by setting a custom rule (using the Custom Rule option from the View menu in the Projects row) that team members can only view projects where Region - Current User Count is greater than 0 in order to eliminate projects outside their region.
Now, here’s a little shortcut. Let’s choose the Custom Rule option again for Tasks. Because Tasks haven’t been related to Regions, we can’t use the Current User Count field. We could set up a lookup field on Tasks to pull it down from Projects, but since we’ve already set permissions for Projects we can just check if the team member can view the project associated with the task. So we'll create a custom rule that says team members can only view tasks where the project name is not equal to blank. (Just leave the field blank.)
In doing so, we’ve leveraged the relations we’ve created between Employees, Regions, and Projects to easily specify user permissions for tasks in our app.
If you run into any trouble, search the QuickBase App Exchange for “Regional Project Manager” and you can get a copy of the app we built to take a look at how it works.
A low-code platform that scales
Traditionally, relational database schema could only be changed by a rigorous change control mechanism overseen by database administrators. This is because the performance of queries and other CRUD (create, update, and delete) operations could be greatly affected by how the schema is designed.
Part of the innovation of these low-code platforms has been to relax these constraints so that schema changes can be made without the user having to worry about impacting performance. It is the job of the platform to scale these operations and optimize the performance automatically so that users can concentrate on customizing the apps to their requirements. QuickBase, as shown above, provides a point-and-click UI to build the schema, and no special skills are needed to optimize queries. All operations are optimized on the fly as the changes to schema are being made.
Normally if you have very fine-grained permissions there’s a scaling challenge. This is because layering on fine-grained permissions is like introducing additional query clauses for every request (and not just for queries). QuickBase relies on its dynamic optimization capabilities to layer in the necessary permissions to all aspects of access so that users do not need to worry about information leakage once they have defined their roles and assigned users to those roles. It also does this with minimal overhead so that users can express complex permissions and hierarchies that model their application needs.
The scalability of any system is often affected by the disruption caused when changes and customizations need to be made. In QuickBase, delivering new application changes does not require rebooting the application. Rather, users can update the application, including data or schema transformation, without logging off.
This is an important distinction as developers can apply updates in real time without any disruption. It’s the ultimate example of continuous deployment because when a change is made, it’s immediately available to the business. When compared to traditional relational database applications, QuickBase applications require little to no downtime for changes.
Taming complexity is a key component to successful application design in any system, and the same rule applies to QuickBase. Keeping the data model simple and efficient will help to ensure a long-lasting and scalable application. Minimizing field types, formula fields, and cross-table references that span multiple layers of a relationship tree will help ensure you are set up for success.
Managing all of these elements is no easy task. (Indeed, in most development platforms, managing these elements is left to professional architects.) It can become even more challenging when you are attempting to spin up an application in just hours or days and you don’t have time to work up a formal data model or call on a seasoned architect. This is where the QuickBase app model, ease of use, and continuous deployment play key roles in enabling you to adapt your design on the fly. When you can add, remove, or copy objects with just a click, you can develop and optimize your app in almost no time at all.
Although business users may be taking on more of the application design process, the burden lies on IT to ensure that the apps created by non-programmers uphold SLAs for performance and security. Low-code platforms that enable users to codelessly embed governance and scalability at the core provide a user-friendly way to meet these needs. Meanwhile, IT can still hold the master key to ensure that applications stay up and running and secure.
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to firstname.lastname@example.org.
Soumya De is an architect for QuickBase, a platform for building customizable applications. He has designed and written software for SaaS and cloud platforms for more than 15 years. Sam Jones is a product manager for QuickBase, working on next-generation user experience.