Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Workspace Invites Settings Block for React

Join rules for a workspace: a domain rules table with a role menu and approval switch, a form that checks a domain before adding it, a field that tries an email address against the rules, and a queue of join requests to approve or decline.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Let admins decide who can walk in and who waits with this workspace invites panel for React with Base UI. A native table lists the domain rules: for each domain the role people from it join as, in a Native Select, and an approval Switch that says At once or Asks first. A form adds a rule only after checking the domain: it must be a plain domain, not already covered, and the table holds at most six rules, and the one Shine Button adds it. A field tries an email address against the rules and answers in one sentence: casey@example.com would join as Member at once. Below it a queue of join requests shows who is waiting, the role they asked for and the rule that holds them, with Approve and Decline in each row, and Undo once a request is answered. Changes apply on the spot and one status line says what changed and that nobody was emailed. On a phone the rules are cards. It's built from Native Select, Switch, Input, Avatar, Button, Shine Button and Guides, with a CSS entrance only. For a community, a client portal or any product people join from a company address.

FAQ

How do I fill it with my own rules and requests?

Edit RULES (a domain, the role it joins as and whether it asks for approval), REQUESTS (a name, an address, the role they asked for and their state) and JOBS (the roles a rule can give). The sentence under the rules table, the counts, the try-an-address answer and the line under each request are all worked out from those lists, and MAX_RULES is the limit the add form enforces.

How does an address match a rule?

By the domain after the last at sign, compared exactly and without regard to capitals. A rule for example.com does not cover mail.example.com; add that domain as its own rule if you want it. An address with no rule says No rule covers it and needs an invite, and an address that isn't complete yet says so instead of guessing. Requests show the same logic as a line under the name: the rule that holds them, or that no rule covers their domain.

What does the add form refuse?

An empty domain, an address with an at sign in it, anything that isn't a plain domain (spaces, slashes, wildcards or a missing dot), a domain that already has a rule and a seventh rule. Each refusal is a one-line reason under the field, the status line says the rule was not added and focus stays on the field. New rules ask for approval until you turn that off, which is the safe default.

What stays local, and how do I make it real?

Everything. Rules and answers only change the lists in the page; an approved person is not emailed and nobody joins. To make it real, send each change from addRule, changeJob, changeAsk, removeRule and answer to your server, let it send the invitation or the decline, and replace the lists with its answer. Keep the same rules there, since a form in a page can be bypassed.

How does it work with a keyboard and a screen reader?

Tab runs through each rule's role menu, approval switch and Remove, the add form, the try field and each request's buttons. Every control is named for its domain or person ("Joins as, example.com", "Approve Zainab Quartey"). When a button is replaced, as Remove or Approve is, focus moves to the next rule's Remove or to the answer's Undo. A reason under a field is tied to it with aria-describedby, and the status line is the one live region.

How does it look on a phone?

Each rule is a card with its domain and Remove, then the role menu and the approval switch on their own lines. The add form stacks its fields, and each request shows its buttons under the person.

  • Pro

    Team Members Settings

    Team and roles

    A members panel with seat and two-factor meters, a native table with row selection, a role menu per person and, pinned at the foot, a bulk role change and Remove that an Undo walks back one step at a time.

  • Pro

    A roles window with a rail of five roles and a detail of grouped permissions: mixed-state group boxes, a Compare with select that marks each permission with a plus or a minus, read-only system roles and Duplicate to edit.

  • Pro

    Invite Members Dialog

    Share and invite

    A household calendar's Members page with its invite dialog shown open: one email field that knows the household's domain, so an outside address joins as a guest, the people who already have access, and a Send invite button that adds a pending row.

  • Pro

    SAML Setup Settings

    Sign-in and security

    A SAML single sign-on setup sheet shown open over a drawn security page: copy two values, paste the provider's metadata and see what is found (including the certificate's end day read from the certificate), run a local test, then enforce.

  • Pro

    Audit Log Settings

    Alerts and audit

    A settings change history in a fixed-height window: changes grouped by area in folds with counts, an actor filter, and a detail pane with the before and after values, who and when, and a Revert that undoes only the latest change to a setting, marks the original and adds a revert event at the top.

  • Pro

    Six collaboration rules beside a live preview: pick Member, Editor or Guest and a drawn document with a comment thread plus five rows say what that person can view, comment on, reply to, resolve and mention, and why.