Defining who could act, where permissions appeared, and how changes became traceable.

Multiple accounts introduced a new question: what could each person do?

The account foundation behind Charitable Allowance made new giving relationships possible. It also created access questions that reached beyond a single interface. Permissions needed to behave consistently in customer journeys, the internal Ruby on Rails administration application, and the data flows that connected the system.

Role-based access was one of the four foundational Charitable Allowance infrastructure releases.

A role name was not enough; every permission needed a consistent product rule.

• Define the responsibilities and allowed actions for an Impact Account Owner and Impact Account Administrator.
• Trace those permissions across all relevant customer use cases and surfaces.
• Specify how backend users could see and manage roles without creating a second, conflicting model.
• Describe the underlying data flows and capture sensitive role or permission changes.
• Create a foundation that could expand beyond the initial Charitable Allowance scope.

Treat permissions as a connected system, not a set of isolated controls.

1. Inventory the use cases. I mapped where Owner and Administrator responsibilities mattered across customer and internal experiences.
2. Make permission decisions explicit. Requirements defined allowed actions, role visibility, and how backend teams would manage each role.
3. Follow the data. I worked with engineering to connect the experience rules to the underlying data flows and state changes.
4. Design for traceability. I co-built the audit system and CDC pipeline, initially covering role and permission changes before coverage expanded across the product.
5. Carry the model through delivery. Stories, acceptance criteria, UAT, and release-readiness activities kept the behavior aligned across teams.

Public evidence boundary.

The source materials behind this work include permission matrices, surface inventories, audit-event formats, and CDC flow notes. The public version explains the evidence boundary without exposing internal controls or production data.

The first audit scope became a reusable product foundation.

Owner and Administrator roles shipped as part of the Charitable Allowance foundation. The audit and CDC work began with role and permission changes, then expanded to cover other areas of the product. This establishes delivered scope and extensibility, but it does not establish a measured reduction in access incidents or operational effort.

Good access design makes policy visible in everyday product behavior.

Permissions become trustworthy when the same rule survives the customer interface, internal tooling, and the data underneath both. This public story focuses on the decision points that made the role model clearer and the traceability boundary behind role changes.