figma guide
Designing third-party app approvals and marketplace UI in Figma: OAuth consent, allowlists, and handoff
Design third-party app approval and marketplace UI in Figma with app catalog, OAuth consent, org allowlists, scope review, and Dev Mode specs for enterprise integration admin.
- Published
- Updated
- Jul 16, 2026
- Read time
- 8 min
- Level
- Intermediate
Quick answer
Third-party app approvals control which integrations members can install—configured under Organization → Security → Apps & integrations. Design an org app catalog (approved, blocked, pending); member install flow with scope disclosure before OAuth consent; admin approval queue for new app requests; scope comparison table (read files, write comments, org admin); revoke and offboard hooks tied to member deprovisioning; and usage audit in security activity. Start from the Figma guides hub and pair with connected accounts, API keys, and DLP.
Who this is for
- Product designers building enterprise integration settings, OAuth consent screens, and marketplace admin.
- Design system teams aligning app cards with cards and permission copy with team roles.
- Engineers implementing allowlist enforcement, token revocation, and scope diff on app updates.
App governance entry points
| Location | Audience | Actions |
|---|---|---|
| Org → Security → Apps & integrations | Security admin | Allowlist, blocklist, approval queue |
| Marketplace / Community | All members | Browse; install gated by policy |
| OAuth consent screen | Installing member | Grant scopes |
| Member → Connected apps | End user | View/revoke personal installs |
| Audit log | Security admin | Install, revoke, scope change events |
Verdict: central Apps & integrations admin page plus consent screen at install time—policy invisible until blocked installs frustrate users.
Org app catalog states
| State | Member experience | Admin UI |
|---|---|---|
| Approved | Install without extra approval | Green status in catalog |
| Approved with restrictions | Install; limited scopes | Badge: “View-only scopes” |
| Requires approval | Request → admin queue | Pending count in nav |
| Blocked | Hidden or “Not allowed by org” | Block reason in admin |
| Deprecated | Existing installs work; no new | Sunset date shown |
OrgAppCatalogTable
├── Tabs: Approved (24) · Pending (3) · Blocked (8) · All
├── Columns: App · Publisher · Scopes · Installs · Status · Actions
└── Toolbar: [ Add to allowlist ] [ Import blocklist ] [ Review pending ]App card and detail drawer
Marketplace and admin views share a consistent app detail pattern:
AppDetailDrawer
├── Logo + name + publisher (verified badge)
├── Description + privacy policy link
├── Scopes requested: bullet list with plain-language explanations
├── Org status chip: Approved / Requires approval / Blocked
├── Install count: 142 members · 3 teams
├── Last scope update: Mar 12, 2026 — "Review required" banner if breaking
└── Actions: [ Approve for org ] [ Block ] [ View audit ]| Scope | Plain-language label | Risk tier |
|---|---|---|
| Read files | View files you can access | Low |
| Write comments | Post and edit comments | Low |
| Read org membership | See member list and emails | Medium |
| Manage webhooks | Create org-level webhooks | High |
| Admin actions | Change org settings | Critical |
Use risk tier colors sparingly—pair with text for accessibility.
Member install and OAuth consent
When policy is requires approval or blocked, intercept before OAuth redirect:
InstallBlockedModal
├── App: Acme Sync for Jira
├── Status: Not on your organization's approved list
├── Actions: [ Request admin approval ] [ Cancel ]
└── Link: Why can't I install?Approved apps still show consent screen with scope checklist:
OAuthConsentScreen
├── App logo + "Acme Sync wants to access your Figma account"
├── Scopes:
│ [x icon] Read files in teams you belong to
│ [x icon] Post comments on your behalf
├── Org note: "Approved by IT · View-only data access"
├── Checkbox: [ ] I understand this app can read file content
└── [ Deny ] [ Authorize ]Critical scopes require explicit checkbox—not pre-checked—for SOC2-friendly consent.
Admin approval queue
| Column | Spec |
|---|---|
| Requested | Timestamp + requester |
| App | Name + publisher |
| Scopes | Diff vs org default template |
| Justification | Member-provided reason |
| Similar approved | ”Like Slack plugin (approved)“ |
| Actions | Approve once / Approve org-wide / Deny |
ApprovalQueueRow
├── Requester: jane@acme.com · Design team
├── App: Vendor DAM Connector · scopes: read files, export assets
├── Justification: "Need asset sync for Q3 campaign"
└── [ Approve for requester ] [ Approve for org ] [ Deny ]Approve for org adds to allowlist—future installs skip queue if scopes unchanged.
Allowlist and blocklist management
| Action | UI | Audit event |
|---|---|---|
| Add approved app | Search marketplace ID or paste URL | app.approved |
| Block app | Block with reason; optional notify installs | app.blocked |
| Scope template | Max scopes any app may request | app.policy.updated |
| Publisher trust | Allow all from verified publisher | publisher.trusted |
AddToAllowlistModal
├── Search: [ slack ▾ ]
├── App: Slack Notifications v2.4
├── Scope ceiling: [x] Read files [x] Post comments [ ] Org admin
├── Auto-approve future scope patches: ( ) Yes (•) No
└── [ Cancel ] [ Add to approved list ]Auto-approve scope patches should default off—app updates that add scopes trigger re-approval.
Scope change and re-consent
When a publisher ships new scopes, existing installs enter review required:
| Scenario | Member UI | Admin UI |
|---|---|---|
| Minor scope add | Re-consent banner on next use | Pending re-approval count |
| Critical scope add | App disabled until re-consent | Alert Security Admin |
| Publisher change | Block + force uninstall option | Migration wizard |
ScopeChangeBanner
├── "Acme Sync updated permissions — review before Mar 20"
├── New scope: Export files (previously not requested)
└── [ Review and authorize ] [ Revoke access ]Admin dashboard: apps with drift from approved scope template highlighted.
Revoke, offboard, and token lifecycle
Tie to member offboarding and connected accounts:
| Event | Behavior |
|---|---|
| Member offboarded | Revoke all user OAuth tokens for org apps |
| App blocked | Grace period banner; then hard revoke |
| Admin revoke | Immediate; notify affected members |
| Sponsor leaves | Revoke guest-scoped app tokens if applicable |
RevokeAppAccessModal
├── App: Legacy CRM Sync · 89 active connections
├── Effect: Members lose sync immediately
├── Reason: [ Required ] Security review failed
└── [ Cancel ] [ Revoke all org access ]Log revocations to audit log with actor, app ID, member count.
DLP and data egress alignment
Data loss prevention and classification labels apply to app exports:
| Control | Spec |
|---|---|
| Confidential file block | App cannot read Restricted-labeled files |
| Export scope cap | Approved apps max at read-only |
| Webhook payload filter | No PII in outbound events—link webhooks |
| Audit on app read | Log app.file.access for Confidential+ |
Settings note: “App policies stack with DLP—most restrictive wins.”
Developer-built vs marketplace apps
| Type | Approval path | UI difference |
|---|---|---|
| Marketplace public | Standard catalog + queue | Publisher verified badge |
| Private org app | Admin uploads client ID | Internal-only badge |
| Personal API token | Separate from OAuth—link API keys | Not in marketplace |
Do not conflate OAuth apps and personal access tokens in the same table—cross-link with clear labels.
Common mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Scope jargon on consent | Members over-grant | Plain-language scope list |
| No approval queue | Shadow IT via personal tokens | Gate install + monitor API keys |
| Block without uninstall path | Orphan tokens active | Revoke job on block |
| Scope updates silent | Over-permissioned apps | Re-consent on diff |
| Marketplace shows blocked apps as installable | Click → error frustration | Hide or show blocked state early |
| No publisher trust option | Admin approves same vendor 20× | Trust verified publisher |
| Offboard ignores app tokens | Ex-employee access persists | Revoke on deprovision |
| Apps bypass classification | Data leak via integration | Evaluate label on app read |
| Consent checkbox pre-checked | Compliance failure | Explicit opt-in for critical scopes |
| Admin and member app views differ | Confusing status | Shared app detail component |
Recommended workflow
- Design org app catalog with approved, pending, blocked tabs and scope summary.
- Build OAuth consent screen with plain-language scopes and org approval note.
- Add install intercept for blocked and requires-approval states with request flow.
- Create admin approval queue with approve-once vs approve-org-wide actions.
- Spec scope change re-consent banners and admin drift dashboard.
- Wire revoke to offboarding and blocklist hard-revoke jobs.
- Link DLP and classification rules for app file access in Dev Mode.
FAQ
Are Figma plugins the same as OAuth apps?
Related but distinct—plugins run in-editor; OAuth apps use REST API. Admin may need separate allowlists or unified “integrations” view with type filter.
Can teams override org app policy?
No—org allowlist is ceiling; teams cannot approve blocked apps.
How do apps relate to webhooks?
Apps may register webhooks—show webhook scopes on consent; admin revokes webhooks when app blocked.
Personal token when app is blocked?
Separate policy—org can disable personal tokens or restrict scopes; link from Apps settings.
Monitor mode for new app policy?
Recommend log-only period—track app.install.attempted blocked events before enforce, similar to DLP monitor mode.
Next steps
- Design connected accounts and OAuth linking UI in Figma — member-side app connections
- Design API keys and personal access tokens UI in Figma — non-OAuth automation paths
- Design webhooks and event subscriptions UI in Figma — app-driven outbound events
- Design DLP and external sharing restrictions UI in Figma — app egress policies
- Design content classification and sensitivity labels UI in Figma — label gates on app file access
§ Keep reading