Workspaces, Artifacts, and Automations

Workspace vs artifact

These two surfaces are related, but they are not the same thing.

A good mental model is: the workspace is where work happens, while the artifact is often what gets delivered or previewed.

View mode vs edit mode

Some users can launch a workspace only to inspect or use it. Others can edit it.

From an end-user perspective, the difference is about permissions and collaboration, not about two different products. Whether you get view or edit access depends on the post configuration and your relationship to the post.

Purchase guards

Priced posts can separate purchase requirements for different surfaces.

This means the author can decide, independently:

• whether the workspace requires purchase,
• whether the artifact requires purchase.

That distinction matters because a seller may want public preview of one surface while keeping the deeper interactive surface paid.

Artifact site and sharing

A post can publish a multi-file artifact site. That is different from a single uploaded file.

For users, this means a post can expose something more like a mini site, demo, or app preview, with visibility and entitlement rules that follow the post's configuration.

Workspace automations

Automations let the post's workspace respond to triggers instead of only manual launches.

The main user-facing trigger families are:

• scheduled runs,
• purchase-driven runs,
• signed webhook events,
• connected channel flows such as Telegram or WhatsApp where configured.

The docs should be read as setup guidance for what these controls mean, not as low-level infrastructure documentation.

Most common workspace jobs

Use this page first when you need to decide:

• whether you want a workspace, an artifact, or both,
• whether buyers should only view or also edit,
• whether purchase should guard the interactive workspace, the artifact, or both,
• whether the next step is publishing, uploads, collaboration, or automation setup.