---
title: "@elevasis/ui"
description: The shared React 19 feature-shell and manifest-backed feature modules for Elevasis — Lead Gen, CRM, Projects, Operations, Monitoring, Settings, SEO, and more. Embeds into any host UI via ElevasisProvider.
---

`@elevasis/ui` is the shared React feature-shell for the Elevasis platform. It provides an `ElevasisProvider` and a set of manifest-backed feature modules that a host UI embeds and composes. The model is: your shell owns the layout and routing; Elevasis features plug in as self-contained modules.

## Install

```bash
pnpm add @elevasis/ui
```

Many peer dependencies are optional. Pull only the peers that the features you use require. If you are not using the graph visualization features, you do not need `cytoscape`. If you are not using TanStack Router, you do not need it either.

## Peer Dependencies

`@elevasis/ui` has a broad peer dependency set. The required peers are React 19 and Mantine 8.2.7. Most others are optional and only needed when specific feature modules are activated.

- **React 19** -- required. The feature modules use React 19 APIs.
- **Mantine 8.2.7** -- required. The component layer and theming foundation.
- **TanStack Query** -- required for data-fetching features (most modules).
- **TanStack Router** -- optional; required if you want the routing-aware feature shells.
- **Zod 4.1** -- required for schema validation in form-backed features.
- **Zustand 5** -- required for state management in multi-panel features.
- **cytoscape** -- optional; required for the graph/knowledge visualization modules only.

## Provider and Feature-Shell Model

The entry point is `ElevasisProvider`, imported from `@elevasis/ui/provider`. Wrap your application root with it to give all child feature modules access to the platform context, auth session, and manifest registry.

```tsx
import { ElevasisProvider } from "@elevasis/ui/provider";

export function AppRoot() {
  return (
    <ElevasisProvider config={elevasisConfig}>
      {/* your shell and routes */}
    </ElevasisProvider>
  );
}
```

Feature modules are imported from their own subpaths (e.g. `@elevasis/ui/features/lead-gen`, `@elevasis/ui/features/crm`) and rendered inside the provider tree. Each module is manifest-backed: it reads the platform manifest at runtime to know which resources and workflows are available, so no hard-coded resource IDs are needed in the host UI.

## Available Feature Modules

The published feature surface includes modules for:

- **Lead Gen** -- prospecting pipeline, campaign review, acquisition workflows
- **CRM** -- client management, deal tracking, contact records
- **Projects** -- task tracking, project lifecycle, milestones
- **Operations** -- workflow execution history, operations dashboard
- **Monitoring** -- execution health, error log, platform diagnostics
- **Settings** -- organization settings, credential management, member management
- **SEO** -- content and SEO tooling modules
- **Notes** -- note capture and structured annotations
- **Knowledge** -- knowledge base viewer and search UI
- **Dashboard** -- compatibility components for host-owned dashboard shells

Each module has its own `@elevasis/ui/features/<name>` subpath. See the [Export Catalog](exports.mdx) for the full generated list.

## When To Use @elevasis/ui

Use `@elevasis/ui` when you are building a host application that needs to embed Elevasis features -- lead-gen pipelines, CRM views, operations dashboards -- without re-implementing them. The provider/feature-shell model means you own the shell, navigation, and layout; Elevasis owns the feature logic and UI internals.

You do not need `@elevasis/ui` if you are only writing backend workflows and agents. Tenant automation projects use `@elevasis/sdk` alone.

## Composition With @elevasis/core

`@elevasis/ui` uses `@elevasis/core` internally for entity schemas, org-model types, and auth contracts. Installing `@elevasis/ui` will pull in `@elevasis/core` as a dependency. You do not need to install `@elevasis/core` separately unless you need direct access to its subpaths.

## Export Catalog

See [Export Catalog](exports.mdx) for a generated table of all published subpath exports derived from the reference manifest.
