Role-based access control becomes necessary the moment a founder-led firm crosses ten people. Owner sees everything, everyone else sees their slice. The approval workflows that matter are fewer than you think.
By Mohammad Jamnagarwala · Simply Five Studio
A founder running a twenty-eight-person trading business asked us to add "user permissions" to the ERP we had built two years earlier. The literal request was a settings page where he could check boxes for each user. The actual problem was that the firm had grown past the point where everyone could see everything, and the boundary that had been informal until now needed to become structural. The settings page was the surface. The underlying question was who-sees-what, and under what conditions a decision moves up a level.
This is the role-based access control conversation, and it arrives in every founder-led firm somewhere between ten and thirty employees. The conversation has fewer good frameworks than it should. This essay is one.
Up to about ten people, RBAC is unnecessary. The team is small enough that the founder knows what every person is doing. The information that flows through the firm is small enough that any team member can usefully see most of it. The cost of restricting access exceeds the cost of leaving it open. The right answer is no formal access control beyond the obvious (finance staff see finances, sales staff see sales, the founder sees everything).
Past about ten people, the calculus inverts. New hires do not have the context to interpret the full data set. The senior team's informal authority gets diluted as the org grows. Customers and vendors begin to ask whether sensitive numbers are protected, and the honest answer of "everyone here is trustworthy" stops being a sufficient answer.
The transition is rarely smooth. The team that has always seen everything resents being asked to see less. The founder, who has always operated on full visibility, struggles to define which information specifically should be partitioned. The first attempt at RBAC is usually too restrictive or too loose, and gets revised within three months.
The principle that holds across the firms we work with is short. The owner sees everything. Everyone else sees their slice plus adjacencies. Nothing is hidden as a category; some things are hidden by relevance.
Sales staff see the sales pipeline, the customers they own, and the inventory available to quote. They do not see other salespeople's pipelines except in aggregate reporting. They do not see purchase costs, margins, or vendor relationships. They see the customer record at full depth for customers they own, and at summary depth for customers they do not own (so they can recognise when a colleague is already in conversation with a lead they are about to call).
Purchase staff see vendor records, purchase orders, inventory, and the receipt against orders. They do not see the customer-facing pricing, the sales pipeline, or the margins. They see goods-in movement at full depth and goods-out movement only at the inventory balance level.
Finance staff see all financial flows but not the customer or vendor relationship context that drives them. The CA's office, where relevant, sees only what is needed for statutory work.
The founder sees all of the above and the reports that consolidate across them.
This frame produces a small number of role definitions that fit most twenty-to-fifty-person businesses. The list of roles is shorter than the list of people. Most firms end up with four or five role templates and then a handful of named overrides for senior team members who carry combined responsibilities.
Beyond access control, the second question RBAC enables is approvals. Approvals are not about restricting work; they are about routing decisions to the level where the consequences are understood. The approval workflows that consistently matter across founder-led firms are four.
The first is purchase orders above a threshold. The threshold varies by firm, commonly fifty thousand to two lakh rupees for the founders we work with. Below the threshold, the purchase head approves. Above, the founder or the partner with financial authority does. The system enforces the routing. The team learns the boundary in a week.
The second is customer credit-limit overrides. A salesperson wants to take a fresh order from a customer who is at the credit ceiling. The system blocks the order pending approval. The approval routes to the finance head or the founder depending on the over-limit amount. The override decision is logged with reason.
The third is refund issuance. Refunds are the moment customer-facing decisions interact with money outbound from the firm. The pattern we recommend is that any refund above a small floor (typically the order value of a single SKU) routes to a named approver. The reason is logged. The pattern of refunds, by customer and by reason, becomes a report the founder reviews monthly.
The fourth is price overrides below a published rate card. The salesperson wants to drop the price for a customer. The system allows it up to a tolerance, then routes for approval. The threshold reflects the firm's gross margin discipline, not a generic percentage.
These four workflows cover, in our experience, ninety percent of the structural approval need in a founder-led firm. Adding more slows the operation. Adding fewer leaves visible holes.
At Carbiforce, Metaldur, and Kawacut, the three-brand operational system uses tenant-level role definitions that mirror the brand structure. A purchase head in Carbiforce does not see Metaldur's procurement queue. A salesperson assigned across two brands sees both, scoped by the brands they are attached to. The founders see consolidated reporting across all three. The system enforces the boundaries automatically because the firm asked for it before scale forced the question.
At AKSD, the ERP that sits behind the WooCommerce storefront uses role-based scoping on customer records and order data. The team that handles online orders does not see the offline distributor relationships that the founder manages directly. The reporting layer is the founder's, with selective slices exposed to the team leads.
In both cases, the RBAC design was not a settings page bolted on after the system was built. It was a structural property of the data model. Every record has an owner. Every query is filtered against the requesting user's role. The interface adapts to the role. The design is invisible when it works, and the alternative of bolting it on later is visibly painful when firms try it.
The risk in approval workflows is that they become bottlenecks. The founder is the named approver on four categories. The founder is also unavailable for half the day in meetings. The team waits. The operation slows. The system is blamed.
The pattern that prevents this is delegation with override. The founder names a default delegate for each category. The delegate approves. The founder receives a daily summary of approvals made on their behalf, with the ability to flag any that should have come up. The team is not blocked. The founder retains visibility. The exceptions get reviewed without forcing every decision to wait.
A longer treatment of the related question (when systems should constrain and when they should inform) is in the essay on three years of one system.
The summary frame is this. Up to ten people, no formal RBAC. Between ten and thirty, a small set of role templates with the owner-sees-everything principle. Past thirty, the same templates with named delegates for the four core approval workflows.
The work we do under the internal systems practice treats RBAC as structural from day one of the build, not a settings page added later. The system enforces what the firm needs at its current size, and scales without rework as the firm grows. The longer treatment of the architecture that supports this is in the decision infrastructure essay.
The firms that get this right do not feel RBAC. They feel the firm running cleanly. The team sees what it needs and not what it does not. Approvals route to the right person without waiting. The founder spends attention on the decisions that need it.
If your firm is in the middle of the RBAC transition right now and the first attempt is not landing, the conversation is worth having. Start a Conversation.
Generic school management software does not understand voluntary contributions, WhatsApp as the parent channel, or the relationship between a tahfeez and its community. A fitted system does.
A premium ceramic and sanitaryware showroom does not sell the way retail sells. The software that runs the floor has to follow walk-ins, designers, and vendor POs as one continuous journey, or it stays in the way.
Indian print-on-demand is artwork-heavy. The operational backbone for a 20 to 100 order-per-day shop covers capture, approval, production scheduling, and dispatch.
The contact form takes about two minutes. The reply comes from the founder within two working days.
