Dani Weidner: Roles and Permissions

THREAD 01 / 03

Finding the risk nobody reported

15

ScopeParticipants, from admins to agency partners

10

ScopeOrganizations, including multi-brand enterprises and agencies

3

DecisionProblems ranked by frequency, severity, and impact

The problem

Customers rarely filed access complaints, so the gap looked small from the inside. The real signal was in their workarounds: admin access handed out too broadly, support tickets to remove people, and in some cases shared credentials.

What I did

I owned the study end to end, from recruiting and the discussion guide through continuous interviews, surveys, card sorting, and prototype sessions, then synthesis. Participants spanned admins, marketing ops, developers, analysts, agency partners, and the legal and compliance reviewers who sign off on access. Ranking what surfaced by frequency, severity, and strategic impact left three problems: no resource-level control, no line between internal and external users, and onboarding and offboarding that ran on memory.

No blocker to report is not the same as no risk. The workaround never shows up in the feedback. Research finding, cross-study synthesis

Fig. The risk lived in the workarounds, not the complaints

THREAD 02 / 03

Scoping access to the folder

3

DecisionRoles, assigned per folder instead of account-wide

2

DecisionUser classes, external limited to explicit shares

3

DecisionCapabilities deferred to keep V1 shippable

The problem

Access was granted account-wide, so anyone who could edit one team's work could edit everyone's. Agencies and contractors got the same reach, often for longer than the engagement lasted.

What I did

I defined a V1 model where roles attach to folders: Admin controls people and settings, Editor manages content, Viewer reads. External users are a distinct class that sees only what is explicitly shared, so least privilege is the default instead of a cleanup task.

Custom roles, approval flows, and SCIM provisioning all had real demand. I recommended deferring them because folder roles and the external boundary closed the highest-risk gaps at a scope an early release could carry, and product adopted the recommendation.

Least privilege works when it's the default. If it depends on an admin remembering, it's a hope. Design principle, access model

Fig. Roles scoped per folder, with a hard line around external collaborators

THREAD 03 / 03

Testing it before engineering did

2

ScopeStudy formats, moderated and unmoderated

2

ScopeParticipant pools, customers and non-customers

4

DecisionAdmin steps designed end to end: invite, change role, reassign, offboard

The problem

Permissions mistakes are expensive to find after launch, because the failure is someone seeing or changing what they shouldn't. The model had to make sense to the admins who set it up and to the occasional collaborators who only work inside it.

What I did

I built the V1 model and its admin flows as a working Figma Make prototype, with user status and access visible at every step. I tested it in moderated and unmoderated sessions with current customers and with people outside the customer base, so it had to hold up without product familiarity.

A roadmap reprioritization paused the build, so there are no launch numbers yet. What exists is a tested direction that de-risks the engineering investment.

Onboarding and offboarding are product experiences. Treat them as back-office chores and access lingers. Design principle, user lifecycle

Fig. The full admin lifecycle, tested with customers and non-customers before the build