Skip to main content
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. 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 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.
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.
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

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.

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: 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.