We are building custom operational tools, even when using traditional tools. We want to see how the systems will interact or behave when multiple people are updating at the same time. If we’re using something like Airtable for the backend, we may face some issues with multiple people using it at the same time. Airtable says that if two or three people are trying to update a record at the same time, it’s going to work on the latest information from whoever updated it last, and that might not necessarily be the most correct one. So, with larger teams, we want to reduce that. We want to make the process a bit longer, especially if we have automations running in the backend. We want the process to take a while. So, with these types of things, it’s best to test before even going forward. Test with a few people at a time to see how it interacts or how the system functions with whatever team size is looking to update information.
It’s not needed so much for a smaller team size, let’s say 10 people or fewer, because what are the chances that three or four people, in a team of less than 10, are trying to update the same information at the same time? It’s not happening. But that is beside the point. You’re going to have to test the environment that these tools or these apps will be in. You’re going to test that environment. Anyone who’s been using the Airtable mobile app to maybe add quick details knows that, after using it for a certain amount of time, you’ll sometimes notice that when you go to access that data on your desktop, the information or whatever you input wasn’t saved, or it wasn’t saved fully. So you just lose that information, and if you’re in a creative role and those ideas don’t come back, that idea is just gone forever. Airtable has a feature on the mobile app that reminds you to close the app and restart it.
Now, different people are using these tools at different times. With traditional tools, it’s not so much of an overkill, and it’s not overwhelming to the system because they’re designed to handle multiple users at a time. But with a custom tool that we’re creating on Airtable, or with certain low-code platforms, there’s the backend, the automated syncing tool that’s carrying that information, and then the frontend. You also have to look at adoption. You also need to look at the creation of empty files or empty records. If you use traditional tools and want to carry out an audit or bring up details at the end of the year, the quarter, or the month to see what was input, chances are, especially with a larger team or a large user base, you’ll see empty records being created or records that look like they were accidentally created. It could be empty tasks or empty projects. You might have some that just have a single letter. They were created accidentally. Or, for custom fields, statuses, dates, or other information, it’s very easy to look at the data and say, “Oh, this was created by mistake.” We want to be able to reduce that.
You have to understand that people are using different devices and different internet connections or internet speeds. It’s not something we can avoid completely, but we’re going to have certain things in place that make it a bit more difficult for submissions to happen without the right fields being filled out. Depending on the tool that you’re using, some traditional tools allow for forms that simply require you to input the details you need, review them, and then submit them. If you don’t input the right information, if you don’t meet the required number of characters, or if you don’t complete the required fields, then you’re not allowed to submit.