Skip to Main Content
D-Tools Cloud Ideas Portal

We actually read these.

Ideas submitted here go to the product team, not into a void. Add yours, vote on others, and comment on what matters to your business.

Talk to our Product Managers live: every other Monday, 1:00–2:00 PM ET → https://www.d-tools.com/cloud-product-office-hours

Created by Dave Kirn
Created on May 9, 2026

Permissions: Granular role-based access controls for sensitive data and actions

Problem

The current permissions model gives a relatively coarse set of controls — primarily module-level access flags. Real-world shops need finer-grained role-based controls to protect sensitive financial data, restrict who can take high-impact actions, and split view-only vs. edit access at the entity level. The right shape varies by shop, but the gap is consistent enough that customers describe it as a recurring source of friction: the choice today is often "give a user broad access and hope" or "deny access and create a manual workaround."

Required capability

  • Per-field visibility controls — e.g., hide job costs, profitability, technician wage rates, internal margin, and internal notes from roles that shouldn't see them.

  • Per-entity view-only vs. edit access (account, project, service call, quote, invoice) rather than module-wide all-or-nothing.

  • Pricing controls — separate "view pricing on quotes" from "edit pricing on quotes," and separate change-order approval from change-order creation.

  • Action-level gates on high-impact operations: approve change orders, adjust project phases, override budgets, mark items installed, post payments.

  • Mobile-specific role profiles so field technicians get a different surface than office staff (e.g., no cost columns, no margin, only the project info they need).

  • Custom roles that account admins can build and assign, rather than being limited to the default role set.

  • Per-record ownership / sharing so a user might have edit rights on projects they own and view-only on others, without standing up separate roles for every variation.

Why it matters

Permissions are a hard requirement once a shop crosses ~10 employees or starts running multiple roles in the office (sales, project management, accounting, service, ownership). The lack of granular controls forces shops into one of two unhealthy patterns: over-share (everyone sees costs and margins, including reps who shouldn't) or under-share (lock people out and create shadow spreadsheets that defeat the system of record). It's also a frequent dealbreaker on the way in — prospects who handle sensitive client data or have a payroll structure they can't expose to staff bounce on the demo when this comes up. Solving permissions properly is foundational to growing the platform into larger shops and into adjacent verticals (security, MDU) where role separation is non-negotiable.

What permission settings are you running into limits on, or wishing you had? Drop a comment with your specific scenario. The more concrete examples we collect, the better we can scope this into something useful.

  • Attach files