# Find permission-denied friction in B2B apps

> Surface users and accounts repeatedly hitting 403s, role gates, or missing-seat paths so product can fix admin and permission UX.

## Agent adaptation contract

- Canonical human page: https://agentry.sh/workflows/permission-denied-friction
- Execution mode: on_demand
- Immutable automation template: none
- Applies to: b2b-saas, enterprise-sales, internal-tool
- Required example events: permission_denied
- Required Agentry resources: none declared
- Do not use when:
  - Do not use until the example events are mapped to observed project signals, the current onboarding state is verified, and live event/property reads prove the required data is present.
  - Do not recommend this when the product has no stable account or workspace identity.
- Ask before using:
  - Which observed events map to permission_denied? Is the current onboarding state verified, and do live event/property reads show non-synthetic traffic for them?
  - Which live properties provide permission_denied.account_id, permission_denied.feature, permission_denied.role, permission_denied.required_role, and which stable user or account identifier joins the signals?

This is an adaptable workflow example, not an API recipe. Map event and property names to the project's saved signal map, require status: "verified" from GET /v1/projects/:project_id/onboarding, and confirm the required signals through live event/property metadata and rows. Fetch current OpenAPI or query-blueprint details before making calls. Do not infer unattended authority from this page.

## Why this matters

In B2B products, the buyer and user are often different people. Permission errors are not just security events; they are product friction, support tickets, and expansion signals.

## What you get

- Features most often blocked by permissions
- Accounts where non-admin users repeatedly hit gates
- Role gaps that suggest better invite/admin UX
- Follow-up users for CS or product research

## Walk through it

**You:**
> Where are users getting blocked by permissions?

**Agent:**
> I'll group permission-denied events by account, feature, and role.

```text
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.account_id AS account, properties.feature AS feature, properties.role AS role, properties.required_role AS required_role, count() AS denied_count, count(DISTINCT distinct_id) AS users FROM events WHERE event = 'permission_denied' AND timestamp > now() - INTERVAL 14 DAY GROUP BY account, feature, role, required_role ORDER BY denied_count DESC LIMIT 50"
```

## The output

The agent returns a ranked list and suggests whether the fix is copy, permission defaults, admin nudges, or sales/CS outreach.

## Setting it up

Emit `permission_denied` anywhere the app blocks a user for role or plan reasons. Include both current role and required role.

## Variations

- *"Show only paying accounts."*
- *"Find users who got blocked and then churned."*
- *"Draft a product issue for the top blocked workflow."*