At one point, I think I had gotten pretty good at provocative conversation, without being offensive, when it came to discussing progressive ideas. But since Toby died, I’ve had to work and continue to work very hard to build and maintain energy to get through a day. I don’t have the energy to rehearse talking points in my head, preparing for public council meetings, or the next social media spat.
But I still care about what I care about.
During my lunch today, I started chatting with an older gentleman. I’m not sure what sparked it, but he began to tell me every conspiracy-theory factoid you can imagine, smashed into one steaming hot sandwich.
I immediately felt my energy draining with every point he was trying to make that I wanted to refute. I wasn’t going to get through the day if I did so.
So, I listened, and something interesting happened. Every once in a while, he would say something that seemed to contradict what I would call a typical “conservative” narrative.
He asked about what I do, I mentioned how I work from home. He noticed that a lot of people had been moving north from the city. I mentioned how it’s become crazy-expensive in Toronto, and we both knew that Timmons, Ontario has some of the lowest real-estate prices right now. We both knew that would put pressure on cities to keep their people, and on Northern towns to build out infrastructure for more people.
He noticed that growing season has been starting earlier up north, and that Western Canada has been having drought that’s impacted food production. I mentioned about how the entire province is expected to get warmer because of climate change. And, I even got him to agree that carbon taxation isn’t terrible as long as it can be seen to be doing the work of offloading our reliance on carbon-producing products.
What do these things have in common? Money.
People will believe whatever they want. But take it from someone who no longer has the mental fortitude to argue, it’s not worth trying to break through the compacted layers of mistruths. But if you can find the money toothpick holding that mistruth sandwich together, you might just get someone to pause to think for a beat.
I’m not gonna lie: I’ve become a big fan of Quickbase.
In my history of designing applications, learning to code was necessary to achieve my goals. But Quickbase, for the most part, removes that need and instead lets me focus on data architecture and prototyping with no/low code.
But there are still some aspects of managing Quickbase apps that are a bit of a nuisance, particularly as an app matures, and with it, more Users and Roles are brought on board that require careful management.
But what if table access could be managed more easily, and with more flexibility, using a RACI? This post describes a prototype for doing just that.
What is a RACI?
RACI is an acronym that stands for Responsible, Accountable, Consulted, and Informed. It’s a tool used in project management and organizational workflows to define and clarify roles and responsibilities within a team or across different stakeholders.
Responsible (R): This role refers to the person or individuals who are directly responsible for completing a specific task or activity. They are the ones who perform the work and ensure its completion.
Accountable (A): The accountable role represents the person who is ultimately answerable for the overall outcome or result of a particular task or project. This individual has the authority to make key decisions and is responsible for ensuring that the task is completed successfully.
Consulted (C): This role includes individuals or stakeholders who provide their input, expertise, or advice on a particular task or decision. They are consulted for their insights, but they are not directly responsible or accountable for the task’s completion.
Informed (I): The informed role includes individuals or stakeholders who need to be kept up-to-date on the progress, decisions, or outcomes of a task or project. They are kept informed about relevant information but do not have active participation or decision-making authority.
By using a RACI matrix, teams can define and communicate the roles and responsibilities associated with different tasks or activities. In this example, it will define access permissions for an example table. The neat thing about this method is that it doesn’t require table-to-table relationships, only formula queries. Here we go!
Setting up the RACI table
The RACI table describes who has what permission in which Table. Each Record defines a single instance associating a User to a Table. If a User has access to more than one Table, they need to be defined individually. But, Records can be copied to expedite this process.
I’ve set ordered the fields in my form to create a sort of “RACI statement”, which I’ll demonstrate here also.
Fields To Setup
Users (User)
User Text (Formula – Text)
RACI (Text – Multiple Choice)
Table (Text – Multiple Choice)
Optional: RACI Statement (Formula – Text)
Users
The first field, the “who” field that I’m using, is a simple User field that will display all of the Users of your app. You can use other selectors like groups or teams you’ve defined, as long as you have a way to evaluate and compare in each table.
User Text
This field is a formula text field, and converts the selected Users field to text for evaluating and comparing in other tables.
RACI
The RACI field is a multiple-choice text field, and contains the values Responsible, Accountable, Consulted, and Informed.
How these selections will translate into permissions is completely up to you. I’ll show you an example I’ve put together, that can be copied and pasted into every table of my app where I want to apply the respective permissions.
Table
This is also a multiple-choice text field, that contains table identifiers. It would probably be more effective to use table IDs, but that makes it difficult to read and present. You’ll need to add separate table entities for each table you want to control access to.
RACI Statement
Not essential, but fun. The RACI Statement is a text formula field that uses the formula:
ToText( UserToName( [Users] ) ) & " is " & [RACI] & " for " & [Table]
I think it’s a nice way to confirm the setup.
Setting up a table
In your table where you want to control access via RACI, you’ll need to add 6 formula fields:
Table Name (Formula – Text)
Current User (Formula – User)
Is Responsible? (Formula – Checkbox)
Is Accountable? (Formula – Checkbox)
Is Consulted? (Formula – Checkbox)
Is Informed? (Formula – Checkbox)
Formula: Table Name (Formula – Text)
The formula for the Table Name field is a hard-coded value for the name of the table you’re working in, in this example: “Sample Table”.
There are arguably better ways, such as using the dbid() function. However, for this example, I wanted to focus on something reader-friendly. Whatever the value you use, it must match the value of the “Table” field in the RACI table.
Formula: Current User (Formula – User)
The formula for the Current User field is simply: User()
What it will do is confirm the current user, and match it against “Users” field in the RACI table for subsequent formula queries.
For the next 4 formulas, you’ll need to know how formula queries work, how to locate field IDs, and table shortcuts, which is outside the scope of this post. For more information on that, I suggest checking out Quickbase Junkie tutorials.
Each of these formula queries will check Records in the RACI table to determine what your permissions are in the table you’re using. In this example, the test user is “Responsible” for this table, demonstrated by the automatically checked checkbox. It should be copyable into any table where these formula checkboxes are created.
Adjust Table Access
The next thing to do is adjust table access permissions, and this is where the investment into controlling permissions at the front end pays off.
In this example, Administrators can manage everything, viewers can’t do anything, and Participants can add Records, as well as view and modify them according to Custom Rules.
The View rules are as follows:
The premise for this is simple: If you have any business in this table, then you can view Records.
You can have different rules to determine who can modify Records in this table:
In this example, we can assume that the people with permissions to modify Records are those that are expected to complete tasks, and are accountable for making sure they’re done. People that only need to be informed don’t necessarily need to be able to edit Records but should be able to view them.
While there is some up-front investment of time in setting this up, the benefit is that maintaining app table permissions in the long term becomes much simpler.
What do you think? Do you think a setup like this is worth the time to set it up? Let me know!
They can be useful to resolve complicated issues, bringing together the perspectives of stakeholders at the same time.
But that’s also an expensive use of time. And the value of that investment of time depends on how well-prepared one is for the meeting, and on the clarity of actionable items to come out of them.
Here are some of the tactics I use to help me organize effective meetings, and manage my time around them.
Block time: First thing in the morning, and after lunch
Every business day, I have a repeating schedule to block off time first thing in the morning and after lunch. This gives me time to prepare my action/agenda items for meetings later that morning or afternoon. It also gives me time to check my email in case any of the other attendees have indicated a change to the meeting, either in the agenda, or the schedule.
Block time: Before and after meetings
Back-to-back meetings are. The. Worst. That’s why, with every meeting I schedule, I block off time before and after it.
Before a meeting, this gives me time to transition from my work and prepare for my meeting, including taking a bio-break and refilling my coffee.
After a meeting, it gives me time to consolidate notes and process takeaways, and prepare action items before resuming my work or joining the next meeting.
I also offer this courtesy to my colleagues: I avoid booking a meeting immediately following an event in their calendar, and never on the same day unless it’s urgent.
How do you manage your meeting schedule? Let me know in the comments!
On Wednesday, January 25, I joined my last BikeBrampton Zoom meeting. I said my goodbyes to colleagues and friends that I’ve spent many hours within the trenches of City Hall, trying to make the city experience a little better outside the automobile. Many of them were supportive when Toby was diagnosed with cancer. I’m going to miss them dearly.
I’ll try to make it back to Brampton when I’m able. But it could be a while before the twins are big enough to hold themselves upright and can sit in a bicycle trailer or cargo bike.