# Widgets and Delegated Admin From [Descope Fundamentals](https://learn.descope.io/c/foundations) — Learn the platform by configuring your own project — every module ends in work the app checks for real. Take this course interactively at https://learn.descope.io/c/foundations/widgets-and-delegated-admin --- ![Admin Portal. 2 minutes.](video:widgets-and-delegated-admin-admin-portal) ## Configured in the Console under Widgets → Admin Portal - URL — the hosted link you share or embed - Widgets to host — which appear in the left navigation, and the order you pick is the order shown - Sign-In flow — which flow authenticates somebody arriving at the portal - Style — the style and theme configuration applied It is tenant-scoped, so a user has to belong to a tenant to open it. For someone in several, the tenant query parameter pre-selects which one the portal opens against, which avoids a switcher step you would otherwise have to explain. The theme parameter does the same for light or dark, useful when you are embedding the portal inside an app that already has a theme. > [!NOTE] > Portal configuration can also be managed with Terraform, so it belongs in the same infrastructure-as-code story as the rest of the project rather than being a Console-only setting somebody has to remember to reapply per environment. > [!NOTE] > For letting tenant admins configure their own SSO or SCIM connection, the piece you want is the SSO Setup Suite rather than a widget — that is the self-service configuration experience, and it is covered in the Enterprise Identity course. ![The Admin Portal tab: Descope hosts the widgets for you at the URL shown, so a tenant admin gets a working admin experience with no page of your own. The chips are the widgets it contains, dragged into the order they appear, and the Flow ID below is how the portal signs people in — the same flows and styles as the rest of the project.](widgets-and-delegated-admin-admin-portal) ## Summary - That the Admin Portal is not admin-only, and what a non-admin sees in it - What you configure, including that widget order drives menu order - That it is tenant-scoped, and how the tenant and theme parameters help - That it is manageable with Terraform - Where self-service SSO configuration actually lives --- ![User Management Widget. 2 minutes.](video:widgets-and-delegated-admin-user-management-widget) ## What an admin can do - Create new user accounts - Edit existing user information - Activate or disable accounts - Reset passwords - Remove passkeys - Delete accounts - See how each user was provisioned — SSO via SAML or OIDC, or SCIM That last one is worth more than it looks. In a B2B tenant, "where did this user come from?" is the first question in most access disputes, and the difference between a user who signed up, one who arrived through SSO, and one SCIM created determines who can change them and what happens at the next sync. Unlike the profile widget, this one accepts custom buttons, and each is backed by a flow you write. That is the extension point for anything specific to your product: bulk actions across several selected users, or editing roles for one selected user, without leaving the widget. The table itself is configurable from the Design tab — you choose which columns appear and how they sort. Custom user attributes show up there too, so a tenant-specific field like an employee number is visible to the admin who cares about it rather than hidden behind an API call. > [!WARNING] > This widget requires a role carrying the User Admin permission for the tenant. The built-in Tenant Admin role includes it. If you need an admin who can manage users but not access keys, set required permissions on the individual widgets rather than handing out Tenant Admin. > [!NOTE] > The widget manages user accounts, not how authentication itself works. Changing the journeys stays a Console and developer task, which is the boundary that keeps a customer's admin from redesigning your login. ![The User Management widget in the editor, with its own set of components on the left. The row of buttons above the table is the delegated admin's whole surface — Delete, Reset password, Remove passkey, Disable, Activate, Edit, + User — and each one can be removed if a tenant admin should not have it. That editing is the point: the widget ships complete, and you narrow it rather than build it.](widgets-and-delegated-admin-user-management-widget) ## Summary - The account operations it takes off your support queue - Why the provisioning source is the field that settles access disputes - That custom buttons and flows are the extension point, including bulk actions - How to scope access without granting full Tenant Admin - Where the widget's authority deliberately stops --- ![User Profile Widget. 2 minutes.](video:widgets-and-delegated-admin-user-profile-widget) ## What an end user can do with it - Update their profile picture - Update personal information — name, given name, middle name, family name, phone, email - Manage authentication methods — passkeys, password, TOTP - See every trusted device, and sign out of them - Log out The passkey section lists all the passkeys registered to the account rather than a single entry, which matters because passkeys are per-device: somebody who signs in from a laptop and a phone has two, and being able to see and name them is the difference between managing credentials and guessing at them. You can shape it in the Console. Custom attributes can be surfaced alongside the built-in fields, and individual fields can be marked read-only or mandatory. The behavior behind each component is a flow, so changing what happens when somebody updates their email means editing that flow rather than filing a feature request. > [!NOTE] > One deliberate limit: you can modify the default flow behind each component, but you cannot add custom buttons to this widget. That is the opposite of the User Management Widget, which does accept them — the profile widget is meant to stay a profile widget. There is an optional onReady callback if your surrounding UI needs to know when the widget has finished initializing, which is the usual way to avoid a layout shift as it mounts. > [!NOTE] > This is the one widget optimized for mobile as well as desktop, which makes it the safe choice if account self-service has to work on a phone. ![The User Profile widget in the editor. It is the one widget any authenticated member sees without a special permission, and it covers both halves of a profile: Personal Information, and the Authentication Methods the user can manage themselves — adding a passkey, resetting a password, changing a phone. The component tree on the left shows ten personal-information fields and five authentication methods available to show or hide.](widgets-and-delegated-admin-user-profile-widget) ## Summary - Everything the widget lets a user do, including trusted devices and per-device passkeys - That custom attributes can appear, and fields can be read-only or mandatory - That component behavior is a flow you can edit, but custom buttons are not available here - That it is the only widget optimized for mobile --- ![Widget Overview. 3 minutes.](video:widgets-and-delegated-admin-widget-overview) A widget is a pre-built interface component you drop into your own application with one line of SDK code. It renders against your Descope project — the same users, roles and tenants everything else in this course has been working with — so the screens people need but nobody wants to build are screens you do not build. Editing a profile, inviting a colleague, rotating an access key, reading an audit log: each is a widget rather than a feature on your roadmap. The word for the pattern is delegated administration. Work that would otherwise land on you — a customer asking you to add a user to their account, or to reset somebody's password — moves to the customer's own admin, inside your product, without either of you going near the Descope Console. ## User widgets - User Profile — personal information, profile picture, and authentication methods - Applications Portal — a personalized dashboard of the applications a user can reach - Outbound Applications — the outbound apps a user holds tokens for, and a way to connect to each - Tenant Switcher — for users in more than one tenant, choosing which is active so tenant-scoped roles and data apply in the right context ## Admin widgets - User Management — create, edit, disable and delete users in the tenant - Role Management — create and manage roles and the permissions they carry - Access Key Management — the machine-to-machine keys belonging to the tenant - Audit — visibility into user actions and system events - Tenant Profile — the tenant's own attributes You create one from the Widgets page in the Console, starting from a template or importing a JSON definition. Templates can be filtered by whether they are for end users or admins and by use case, and previewed before you commit. After creating one you can edit both its design and its logic: add, remove or alter buttons and text, restyle the container and the components inside it, and check the result in preview mode, which shows light and dark. Access is permission-based, and the default differs by family. Admin widgets require a role carrying the User Admin permission for that tenant — the built-in Tenant Admin role includes it. User widgets require no special permission at all: any authenticated member of the tenant sees them. For finer control, set required permissions on an individual widget, which is how you let one admin see user management without seeing access keys. > [!WARNING] > Only the User Profile Widget is optimized to work on mobile devices. Every other widget is designed for desktop browsers, which matters if your admin experience is expected to work on a phone. ![The Widgets page, which states the idea in its own subtitle: embeddable components for delegating operations to tenant admins and end users. The eight listed here are the ready-made ones — User Profile, User Management, Roles Management, Audit Log, Tenant Profile, the two access-key widgets, and the Applications Portal. Start from template is how a new one begins; the Admin Portal tab beside Widgets is the hosted alternative to embedding them yourself.](widgets-and-delegated-admin-widget-overview) ## Summary - What a widget is — a pre-built component embedded in your app, rendering against your own project - What delegated administration buys you, and who stops filing support tickets because of it - The two widget families, and that the split is about who the component serves - Which widgets exist in each, so you know what you do not have to build - That widgets are created and edited in the Console, from templates or JSON - The default access rule for each family, and how per-widget permissions narrow it - That mobile support is the exception rather than the rule ---