Workspace isolation is foundational
FoundationThe schema and architecture already model workspace-scoped entities and references across supplier, invoice, job, and notification records.
Security
Controls first. Exposure only when the workflow justifies it.
The security story for PO Walls is not a badge wall. It is a product model built around workspace isolation, explicit permissions, masked review, and a durable trace of sensitive actions.
Security posture
The product is designed around who can see, change, and approve what.
Sensitive actions need explicit permissions
PlannedThe product roadmap treats reveal and trust-data changes as permissioned actions beyond a coarse role label.
Masking is the default review posture
PlannedThe review experience is planned to hide sensitive payment details unless someone has the right context and authority.
Retention is operational, not just policy copy
PlannedHardening work explicitly covers encryption, retention metadata, and deletion-safe workflows for raw and derived files.
Tenant boundaries are structural, not incidental.
The foundational schema already keeps workspaces at the center of the data model. Supplier records, invoices, jobs, notifications, and future permissions all attach to that boundary.
The roadmap treats reveal as a security action.
Controlled reveal, explicit trust-data permissions, and audit trail expectations are first-class product requirements, not UI polish added later.
Review the control model with your own approval workflow in mind.
The right demo for PO Walls is a walkthrough of your supplier-change and invoice-review process, not just a screen share of generic features.