Ethical Walls That Are Actually Enforced on the Server, Not Just Hidden in the UI

Every managing partner I've talked to about ethical walls describes roughly the same setup, right, a lateral hire comes over from a firm across town, or a paralegal's spouse works for opposing counsel on a case the firm is running, or a partner brings in a client that conflicts with someone the firm already represents, and the firm's answer is always the same sentence, "you're walled off from matter 4471, don't touch it." And then somebody in IT goes and hides a tab in the practice management software so that person doesn't see the matter in their sidebar anymore, and everyone treats that as the wall. Let me be very honest about what that actually is, because it's not a wall, it's a suggestion, and the person on the other side of it can still pull the file if they know the matter number and type the URL directly, or if a coworker forwards them a document without thinking twice, or if the app's own API just answers whatever it's asked regardless of who's asking, and none of that shows up anywhere because the system never actually checked whether the person was allowed to be there in the first place. This is the thing I kept running into building Casely and talking to firms about how they actually handle conflicts day to day, so let's get into how a wall that's real, not cosmetic, actually works.

The wall that lives only in the sidebar

Here's the mechanic, and it matters because most practice management software gets this wrong in the exact same way. A typical app checks a user's role when it draws the page, so if you're marked as walled off from a matter, the front end code just skips rendering that matter's card in your matter list, or it grays out the tab, and that gets treated as the security control. But the front end is just a set of instructions the browser follows, and a browser is something the user controls completely, so if that walled off associate opens their browser's developer tools, or just guesses the matter's URL pattern because every other matter in the firm follows the same numbering, they can request the underlying data directly, and if the server hands it over because the server was never told to check, they get the file. Trust ledger entries, notes, documents, all of it, and nobody at the firm knows it happened because there was never a check to fail, so there's nothing to log. Does that make sense, right, the hidden button was never actually protecting the data, it was just protecting the average user from accidentally clicking into something, which is a UX nicety, not an ethical wall, and the bar rules that require walls in the first place don't care whether the button was visible, they care whether the person could actually get to privileged information.

How the check actually runs in Casely

The way we built it, the wall isn't a rendering decision, it's a permission check that runs on the server every single time a request comes in, before a single row of data leaves the database. Casely's role based permissions cover functional areas across the whole platform, documents, the trust ledger, billing, matters, contacts, leads, the calendar, tasks, settings, users, reports, conflict checks, portal access, and audit logs, and a firm admin sets what each role, partner, associate, paralegal, receptionist, can see and do across every one of those areas. For instance, a receptionist role might see the calendar and contacts but nothing in the trust ledger, and that gets enforced the same server side way as a matter level wall does. When an admin walls a specific user off a specific matter, that restriction gets enforced at the same layer, so when that user's browser, or app, or frankly a scripted API call, sends a request for matter 4471's documents, the server checks the permission before it checks anything else, and if the check fails the server just returns a rejection, the same way it would for a completely unauthenticated stranger. The catch here is that this doesn't depend on which screen the request came from, so it doesn't matter if the request came from the normal app, a mobile browser, or someone poking at the API directly, the wall holds because it's not a feature of the screen, it's a feature of the server.

A lateral hire, a conflict, and what happens next

Say a firm brings on a new associate who spent the last three years at a firm representing the other side in an active matter, this happens constantly in small and mid size markets where everyone eventually crosses paths, right. The moment anyone at the new firm types that person's name or the opposing party's name into a new matter or a new contact record, Casely's conflict check runs automatically across the firm's entire contact and matter history, not as a manual search you remember to run in a separate tab, but as something that happens the instant the name is typed, so the potential conflict surfaces before the matter even gets created rather than three months into discovery when somebody finally thinks to check. Once the firm decides the associate needs to be walled off rather than the matter declined outright, an admin goes to the Users page, which already shows 2FA enrollment status per attorney for what it's worth, and restricts that associate's access to the specific matter. From that point forward it's enforced, not requested, so the associate's dashboard won't show the matter, sure, but more importantly, if that associate's account ever queries for it, directly or through a mobile session or through anything else, the server says no, and it logs that it said no.

Where the same philosophy shows up elsewhere in Casely

I'll say this because it's relevant, not because I'm trying to pad the pitch, the ethical wall isn't a one off feature bolted onto an otherwise permissive system, it's the same design philosophy that runs through everything else we built. Two factor authentication in Casely is enforced once a firm turns it on, there's no bypass and no remember this device loophole that quietly undoes it after a week, setup is a QR code and a six digit code and takes under two minutes, with ten recovery codes generated once at enrollment. Sensitive fields, matter notes, trust entries, documents, are encrypted at the application layer with AES-256-GCM per firm, which is a different and stronger guarantee than the database at rest encryption most vendors point to when you ask about security, because app layer encryption protects the data even if someone got at the database directly. And the client portal runs on the identical logic as the ethical wall, a document tagged privileged at upload can never reach the portal even by mistake, because the filtering happens server side on what the client's account is allowed to receive, not as a checkbox you have to remember to leave unchecked on the client facing view. At the end of the day all four of these, walls, 2FA, encryption, portal filtering, are the same sentence repeated in different places, which is that the server decides what a given account can see, and the interface never gets a vote.

What this actually protects you from

Let me be very honest about why this matters more than it sounds like it should, because a hidden tab feels like enough right up until the day it isn't. Bar disciplinary complaints and malpractice claims around conflicts don't usually turn on whether the firm meant well, they turn on whether the firm can demonstrate that access was actually restricted, and "we told them not to look" is not the same statement as "the system made it impossible for them to look, and here's the log proving nobody tried and succeeded." A server side wall gives a managing partner something to actually produce if a wall is ever challenged, a record of the permission, the date it was set, and every access attempt against it, versus a UI toggle that a firm can't prove was ever actually restrictive, since anyone could argue the data was always reachable to anyone who knew where to look. For a five-attorney firm running two or three walled matters a year because of lateral hires or family conflicts or referral relationships, this is the difference between an ethical wall being a policy on paper and an ethical wall being a fact about the software.

Setting it up doesn't slow anyone down

The part firms usually worry about is that adding this kind of enforcement means a bigger, slower rollout, and honestly it's closer to the opposite in practice. The heaviest lift in moving to Casely at all is importing the existing client and matter list, which is achievable in a single pass, and once that's done the trust ledger, conflict checks, and matter stages are live immediately in their fully enforced form, no separate setup step for the wall itself, no support ticket to file, and so on, it's just true the moment the import finishes. A firm running mixed billing models across hourly and flat fee and contingency matters, with thousands of other attorneys on the same platform, isn't sitting on some enterprise only lockdown mode that a small shop doesn't get, it's the same permission engine for everyone, so from the first day a firm is live, walling a matter off a specific person is a two-click action on the Users page, not a professional services engagement.

And so at the end of the day, an ethical wall that only lives in the UI is really just a formality your firm is hoping nobody ever tests, and the honest version of what I'd tell any managing partner reading this is that the test does eventually come, whether it's a bar complaint, a malpractice claim, or just a curious associate who stumbles onto a matter number they were never supposed to see, and when it does, what matters is whether your software actually checked or just politely looked away. Casely checks, on the server, every time, and logs it either way, and so yeah, that is basically the whole case for it.