Knowledge · Customer Experience

    Portal Permissions and Privacy Boundaries

    A portal is a permission decision before it is a feature. Learn the boundaries that keep customer, subcontractor and internal access from leaking into each other.

    What privacy boundaries does a client portal need?

    Three. A customer sees only their own records. A subcontractor sees only the jobs they are assigned to. Internal notes and internal financial detail reach neither. Each boundary must be enforced where data is served, not by hiding elements in the interface.

    Key takeaways

    • Scope is enforced on the server; the interface is not a security control.
    • Customer, subcontractor and employee portals are distinct boundaries.
    • Deny by default: new data is invisible externally until deliberately exposed.
    • Access should be revocable at any moment, by the business.
    • Log external access so 'who saw what, when' has an answer.

    Three separate boundaries

    • Customer boundary — one customer, their own jobs, documents shared with them.
    • Trade partner boundary — a subcontractor sees the jobs they are assigned to, and the operational detail those require.
    • Internal boundary — costing, margin, internal notes and other customers' data never cross either line.

    Why the interface is not the control

    Hiding a field in a page hides it from a polite user. The data still travelled, and anything that travelled can be read. The only durable control is refusing to return the data at all unless the requester's scope allows it.

    That means the scoping decision lives at the point where records are fetched: resolve who is asking, resolve what they own, return only that. Everything the page does afterwards is presentation.

    Deny by default

    New fields, new tables and new attachments should be invisible externally until someone deliberately exposes them. The alternative — external surfaces inheriting whatever gets added internally — guarantees that one day an internal field ships straight to a customer.

    Visibility of access

    • Record when external access happens so it can be reviewed.
    • Store technical identifiers such as address and device details as hashes rather than raw values.
    • Deduplicate repeat opens so the record stays readable rather than noisy.
    • Keep the ability to revoke or expire access in the business's hands.

    Where URBLD fits

    URBLD resolves portal data server-side from the access record, scoped to a single customer within a single organisation, and excludes internal notes. Portal opens are written to the job activity timeline with the address and device details stored as hashes, and repeat opens within a short window deduplicated.

    Principles reinforced

    This page rests on the following foundational ideas.

    FAQ

    Frequently Asked Questions

    Straight answers about how URBLD runs the business end-to-end.

    More in Customer Experience

    What customers actually judge: communication, clarity and reliability.

    Browse Customer Experience
    Share this page