Automated Compliance Permission Profiles

Overview

The permission work covered three Automated Compliance admin roles: full admins with broad product access, partial admins with a scoped subset, and auditors with narrower read-only access. The earlier integration mixed hidden and unavailable states with rules for withholding a whole response or showing only part of it. As the product grew, it became harder to tell what a role should be able to see and whether the UI and backend agreed.

I led the rewrite of Automated Compliance's integration with company permission profiles. That meant making the product's permission rules explicit in the backend and carrying those decisions through to the frontend.

What I built

We moved permission decisions into a unified policy layer and mapped product privileges to the role matrix the app needed. That gave us a common place to reason about what full admins, partial admins, and auditors could do, rather than trying to infer the rules from each endpoint.

The serializers needed to preserve an important distinction: some responses should be returned in full or withheld, while others can expose the subset a user is allowed to see. I made that behavior configurable and explicit so it could be tested without treating every denied field or response as the same case.

Across the covered product surfaces, we aligned backend checks with what the frontend showed or allowed. A permission decision needed to make sense to the person using the product as well as to the endpoint enforcing it.

I also wrote testing helpers for exercising the role combinations. Engineers adding endpoints could reuse the setup for all three roles and concentrate on the access behavior of the new endpoint.

Collaboration

The Automated Compliance backend team helped validate and roll out the permission-profile behavior across covered endpoints.

Outcome

• Covered Automated Compliance endpoints shared the same policy model for full admin, partial admin, and auditor access.
• All-or-none responses and partially visible responses were handled explicitly instead of mixing hidden and unavailable states.
• New endpoints are easier to test against full admin, partial admin, and auditor behavior.

The distinction I kept coming back to was whether data was absent, hidden, or unavailable to this user. Working through those cases made the permissions more understandable on both sides of the API.