A renovation job runs on trades and clients working the same schedule. Neither should ever see the other’s rates, contacts or comments.
Coordination happened person to person, so every new job meant setting up access by hand and answering the same questions again. The visibility rules were the hard part: a trade may not see clients or other trades, a client may not see trades at all, and a CEO may not open another CEO’s jobs. Those rules also apply to invoices: who uploaded one determines who can read it.
We wrote down what each role can and cannot do before designing anything, then built to that as a companion plugin on hooks, so the vendor product stays upgradeable.
Four roles: admin, CEO, client and trade, each defined by what they may do and, more importantly, what they may never do. Only an admin can hard-delete a job or reopen a closed one. Those rules became the specification the dashboards were built against.
A job is created under a client by a CEO, works while active, and closes to read-only: the client keeps its record, trades lose upload access, and only an admin can reactivate it. One client carries unlimited jobs, each mapped to a project in the platform underneath.
The CEO sees active jobs, client summaries, trade assignments, budget against actual and upload approvals. The client sees progress, milestones and permitted invoices. The trade sees only its assigned jobs and tasks. Each opens on the job name, the client address, a status and a click-to-call number.
Internal members, trades and clients register through one structured flow that ends in approval, so nobody reaches job data before someone has granted it. Clients can hard-delete their own account, GDPR style.
An invoice uploaded by a trade is visible to admin, CEO and client. One uploaded by the CEO stays hidden from trades. Either way it is stored against the job as a financial record and feeds the actuals, so billing tracks progress instead of trailing it.
Email is event-based and role-targeted, so a notification never becomes the leak the permission matrix was built to prevent.
The customisation is a plugin on WP Project Manager Pro’s existing hooks. Where no hook existed and a core touch was unavoidable, the change was documented in a change log the client keeps for future upgrades.
Setup that used to be a conversation is now a form and an approval, and the CEO’s office stopped being the router for every question.
Each party opens to the job name, client address, status and a click-to-call number, then only the actions their role owns, so nobody learns the parts of the system that are not theirs.
One structured flow for internal members, trades and clients, with a checkpoint before access, so the right people are inside the system and nobody else is.
Configuration is organised around how the business actually operates rather than by technical category, so an operations lead can maintain it without a developer.
The interesting constraint here was negative permissions. Most project tools are built to make work visible; this one had to make it selectively invisible, with the boundary holding on dashboards, invoices, comments and notification emails alike. Writing the cannot-do list first, before any screen design, is what kept those four surfaces consistent.
Tell us where the friction is. We will map it with you and propose a clear place to start.
