Member-only story
Authorization tables in
The power of linking users to roles and responsibilities
In this post, I want to walk you through the necessity and logic behind what I call an authorization table . It’s essentially a smart table that guides and governs whether an action can be executed or not. Now, these actions can pop up in a couple of ways: through automated processes or good old-fashioned button clicks. In both scenarios, you’ll often need a reliable way to verify who’s got the green light to do what, like hitting an ‘approve’ button.
What makes up this essential table? Well, it boils down to a few key parameters. First off, you’ve got the individual or individuals involved. While you could technically list multiple people per entry, my recommendation, based on experience, is to keep it to one person per row for clarity. Then comes the crucial link to the actual table you’re working with — whether it’s for tracking stock updates, managing inventory, or handling components. I find it helpful to use a ‘Table Type’ identifier for this. This way, when an action (like pressing a button) needs to happen within one of these tables, we instantly know which authorization rules to consult. And finally, we can’t forget the ‘valid from’ date. This is particularly important in dynamic environments where roles and responsibilities can change. Imagine someone on the team…
