> ## Documentation Index
> Fetch the complete documentation index at: https://studio.assembly.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Apps

Apps are how things get done in Assembly Studio. The Messages app handles communication. The Payments app handles billing. A custom app you build handles whatever you describe. Everything in Assembly Studio that does something for your team or your clients is an app.

## What an app is

An app appears in your sidebar with a name and an icon. Click it and you're in the app — a focused interface for one job. Some apps you and your clients both use. Some are just for your team.

Apps install into your workspace. You can configure them, hide them, and uninstall them. The data each app manages is scoped to your workspace.

## Kinds of apps

Everything in Assembly is an app, whether Assembly built it, you built it, or you connected an outside tool. There are three kinds, each covered in depth in its own section.

| Kind               | What it is                                                                                                            | Learn more                                           |
| ------------------ | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| **Built-in apps**  | Apps Assembly builds and ships, like Messages, Payments, Files, and Tasks. Secure, interactive, and ready to turn on. | [Built-in apps](/docs/built-in-apps/introduction)         |
| **Apps you build** | Custom apps built for your workspace with the AI app builder, deployed natively to your portal.                       | [Building new apps](/docs/building-new-apps/introduction) |
| **Embeds & links** | Third-party tools brought into Assembly, either embedded inline through an iframe or opened as an external link.      | [Embeds & links](/docs/embeds-and-links/introduction)     |

Built-in apps and the apps you build are native to Assembly. Embeds and links are how you bring in tools Assembly does not provide directly. For setting up a specific integration, see the [Embeds & links](/docs/embeds-and-links/introduction) section.

## Built-in apps vs custom-built apps

Both kinds of apps are added the same way: click **Add App** in the sidebar. The app builder opens with two tabs — the **Explore** tab lists existing built-in apps and embeds you can install, and the **Build** tab is where you describe a new app and have it built for you.

<Tabs>
  <Tab title="Built-in apps">
    Maintained by Assembly Studio. Ship with your workspace or install from the **Explore** tab. The Messages app, Payments, Contracts, Forms, Tasks, Files, and the rest of the catalog.

    Best when your need matches what the app does. Use a built-in app rather than rebuilding it.
  </Tab>

  <Tab title="Custom-built apps">
    Built by you, in plain English, from the **Build** tab. They install into your workspace the same way built-in apps do.

    Best for the specific workflows your firm has that no generic app captures. Tracking, dashboards, request flows, onboarding sequences, audit trails — whatever your work actually is.
  </Tab>
</Tabs>

The app builder doesn't replace the built-in catalog. Most workspaces will run both — a few built-ins for the universal jobs (Messages, Payments) plus several custom-built apps for the firm-specific work.

## Internal apps vs client-facing apps

<Tabs>
  <Tab title="Internal app">
    One view, one audience: your team. Lives in the Dashboard sidebar. Clients never see it.

    Examples: a team dashboard, a deal pipeline, a hiring tracker, a knowledge base for staff.
  </Tab>

  <Tab title="Client-facing app">
    Three views, two audiences:

    * A global team view in the Dashboard sidebar
    * A per-client team view inside each client's record
    * A client view in the Portal

    The app builder generates all three when you describe a client-facing app. The team views are usually denser and more functional; the client view is simpler and more focused.

    Examples: project trackers, onboarding flows, status pages, request portals.
  </Tab>
</Tabs>

## The three views of a client-facing app

This is the model worth getting comfortable with. The same app renders in three places, each tuned to its surface:

| View                | Where it lives                     | What it shows                                   |
| ------------------- | ---------------------------------- | ----------------------------------------------- |
| Global internal     | Dashboard sidebar                  | All clients, rolled up. Team-wide view.         |
| Per-client internal | Inside a client's record, as a tab | One client's data, from the team's perspective. |
| Client-facing       | Portal sidebar                     | The client's own data, from their perspective.  |

The team views often share a layout; the client view is usually distinct. When you iterate on a custom-built app, think about which view you're changing — sometimes the team view is fine and only the client view needs work.