What this prompt does
This prompt designs a team members and permissions screen for multi-tenant SaaS and returns concrete components and interaction states. It specifies a members table with role dropdowns and status, an invite modal with duplicate-email validation, a roles matrix, search and filter, bulk actions with confirmation, and a per-user audit log in a side panel. The standout safety requirement is locking the current user from self-demotion — and preventing last-owner removal — so no one can accidentally lock the whole team out.
The variables fit the screen to your tenancy model. [roles] defines the dropdown options and the rows of the permissions matrix. [stack] (for example, Next.js with TanStack Table) sets the component conventions. [invite_method] shapes the invite modal — an email magic-link flow differs from a token-based one. [audit_events] populates the side panel, so the log shows the exact events you track, like role changes, logins, invites, and removals.
When to use it
- You are building team management for a multi-tenant SaaS app
- You need a members table with roles, status, and last-active info
- You want an invite modal with role selection and duplicate-email validation
- You need a roles-to-permissions matrix mapped from your role list
- You must prevent self-demotion and last-owner removal lockouts
- You want a per-user audit log panel showing the events you track
Example output
The model returns a component tree with state notes for your stack: a members table (avatar, name, email, role dropdown, status, last active), an invite modal using your invite method, a roles matrix mapping your roles to permissions with self-demotion locked, search and filter by role/status, bulk actions with confirmation, and a side panel showing a per-user audit log of your tracked events. Empty, loading, and permission-denied states plus full keyboard accessibility are included.
Pro tips
- List every role in
[roles]; the dropdown and the permissions matrix are generated from it, so omissions leave gaps - Lock self-demotion and last-owner removal (deliverable 3) before shipping — that edge case is the one that becomes a 2am lockout call
- Set
[invite_method]to your real flow so the modal's validation and success path match - Populate
[audit_events]with the events you actually log so the side panel is useful, not decorative - Match
[stack]to your table library; TanStack Table conventions differ from a plain table implementation - Keep the permission-denied state; users without rights should see an intentional screen, not a broken one
- Put confirmation dialogs on bulk actions like role changes and removals, since a single mis-click across selected rows is hard to undo
- Surface last-active in the members table so admins can spot dormant accounts before a routine permissions cleanup
