Artifacts, Assets, and Workspaces

Use this guide to organize durable work, review generated output, manage reusable files, collaborate on drafts, and publish only an approved live version.

Product model and access

• A workspace groups instructions, documents, skills, chats, apps, and outputs for one business outcome.
• An artifact is a durable saved output such as a document, report, image, data file, dashboard, app, tool, or hosted MCP server.
• An asset is a reusable tenant file referenced by chat, workspaces, branding, artifacts, or coding tasks.
• A draft, an immutable version, and the live artifact are different states with different access and rollback behavior.

Open Apps & Workspaces at /projects, Assets at /assets, or a specific artifact at /artifacts/:id. Visibility and write controls depend on tenant capabilities, ownership, direct sharing, workspace membership, and live viewer policy.

Create and organize a workspace

1. In Apps & Workspaces, choose New workspace.
2. Give it a business-outcome name and concise description.
3. Open the workspace and add stable instructions or documents.
4. Bind only the approved skills needed for its repeatable workflows.
5. Start the workspace main chat or a bounded thread.
6. Save or move owned apps and outputs into the workspace.
7. Use Sharing & access to add only the intended collaborators.

Choose All workspaces or a specific workspace before filtering. The Apps & outputs heading repeats the active scope and item count so the selected workspace is unambiguous. Artifact-type, creator, status, ownership, sort, and text filters apply inside that scope. Clear filters or choose another workspace before concluding an item is missing. Unfiled remains a separate table for apps and outputs with no workspace; only owned items can be moved.

Each artifact row has an action menu that opens Item details, Tests, or Problems directly. Operators with artifact write access also see Artifact symbol. These links open the selected drawer on the artifact page; they do not create another artifact or change its live version.

Choose workspace and artifact symbols

Workspace owners can open the workspace menu and choose Workspace symbol. Artifact owners, editors, and co-authors can choose Artifact symbol from an artifact row menu or from the artifact's Item details drawer. Upload a square PNG, JPEG, WebP, or GIF smaller than 10 MB, or choose Use default to restore the generated symbol.

The uploaded image becomes a tenant asset and the resource stores its asset identity. View-only collaborators can see the symbol but cannot change it. If upload or save fails, the current symbol remains unchanged; retry from the same resource after confirming write access and file type.

Rename, archive, restore, or delete

The owner can rename the workspace, change its symbol, or archive it. Archiving removes it from active navigation without deleting its content or audit history. Use /projects/archived to restore it.

Permanent deletion is a separate irreversible workflow. Topline first inventories apps, artifacts, chats, tasks, schedules, documents, skills, and other dependencies. Deletion remains blocked while dependencies or active work make it unsafe. When eligible, the operator must type the exact workspace name.

Review an artifact

Before accepting or sharing an artifact, verify:

• title, owner, workspace, and intended audience;
• source conversation or coding task;
• current draft, immutable version, and live-version identity;
• data source, generated time, refresh model, and current freshness;
• validation, rendered smoke, and acceptance evidence;
• schedules and external connections;
• sharing mode and sensitive content; and
• rollback or prior live version.

Unsupported or binary files should provide safe download guidance. Raw payload views can contain sensitive data; expand them only when necessary and do not copy them into tickets or chat without redaction.

Artifact-owner deletion is irreversible. The owner deletes an artifact with Delete… in the danger zone of Item details; an app with a managed MCP connection must first be disconnected through Manage MCP connection. Before confirming, review the Data section and any attached schedules. Deleting an artifact permanently removes the artifact, tears down its attached schedules, and drops every registered workspace table labeled artifact_lifetime, including all rows in those tables. Tables labeled operator_managed or with another retention policy are not dropped by artifact deletion. If Topline cannot safely validate or remove an artifact-lifetime table or schedule, the artifact deletion fails instead of silently leaving the requested cleanup incomplete. Historical audit records remain available.

Build and publish an artifact app

Publishing has two steps: make a reviewed version live, then choose who can use it. Deploying a draft, saving an app address, and allowing viewers are separate actions.

First, publish the reviewed version live

1. Open Apps & Workspaces, choose the owning workspace, and open the app.
2. Create or update its private draft through a Topline coding task or Build MCP. Ask for a deployed, validated draft and an operator review link.
3. Review the draft, its data and secret bindings, rendered pages, and required acceptance checks. Open App access and check its Publishing section. When publishing is blocked, Publishing details opens automatically and lists the app status, App readiness, deployment evidence, and publish blockers. A blocked status in the page header, such as Smoke checks required, opens the same place. Resolve any deployment or validation blockers before continuing; use the offered fix button, such as Start app validation, Continue app validation, or Fix with Coding agent, when one appears.
4. Use Publish vN in App access > Publishing for the reviewed version. If the control is unavailable, finish the required checks rather than changing sharing settings to try to bypass the blocker.
5. Confirm that App access reads Live · vN for the intended version. Open the app with Open app in the page header and check its main workflow. Keep the prior reviewed live version available for rollback; Roll back is under Publishing details.
6. As the artifact owner, use App access and Topline access to configure the audience using the workflows below. An editor can publish when permitted, but changing sharing remains an owner action.

A source commit, successful build, deployed private draft, passing HTTP check, or Storybook story is not proof of live promotion. A shared-platform deploy is also distinct from customer-runtime rollout. Build MCP deploys private drafts; live promotion remains an operator action in Topline.

Hosted MCP server artifacts add a connection-review step after promotion. See Build a hosted MCP server.

Share safely

Choose public access or an authenticated workflow

Intended audience	Where to configure it	What the recipient gets
Anyone who receives the app link	App access > Who can use it, set Live app access to Anyone with the link	The live app without signing in
Specific people, including people outside your Topline company	App access > Add app users	The live app after signing in with an approved email
Teammates who need to review or work on the artifact inside Topline	Topline access > Add people with the Viewer or Editor role, or workspace Sharing & access	Authenticated artifact access, including drafts and version history; editing only with Editor access

Sharing uses two drawers, opened from buttons on the right of the artifact page header. Topline access controls who can view or edit the artifact inside Topline. App access controls who can use the live app and holds the app's publishing controls; for documents, reports, and other non-app artifacts the same drawer is called Link access and controls the published link. App addresses are managed in a third drawer, App addresses.

For a finished app shared with a few customers or partners, use the second row. Use the third row when the person should also review drafts or collaborate. Workspace sharing covers contained artifacts, so use a direct artifact grant when they should receive only one item.

Make the live app public

1. Publish a reviewed version live using the steps above.
2. Open App access and, under Who can use it, set Live app access to Anyone with the link.
3. Review the confirmation and select Confirm anyone with the link.
4. Confirm Live app access reads Anyone with the link. Open the main address shown at the top of the drawer (it opens in a new tab), or use Copy app link.
5. Test that link in a separate signed-out browser session. It should open the live version without asking for sign-in.

Anyone who receives or forwards this link can use it. Review the app's pages, downloads, and exposed data before enabling public access. A hard-to-guess URL is not an access restriction.

Authenticated method 1: allow specific live-app viewers

This is the shortest path for a person who should use the finished app without getting access to Topline drafts or editing.

1. Publish the reviewed app live, then open App access. Before the app is live, the drawer says "Publish a live version before sharing the live app. The draft stays private."
2. In Add app users, enter the person's complete email address and select Add.
3. Repeat for each intended viewer. Use the actual address they will sign in with, such as viewer@example.com; this control accepts individual email addresses, not a company-domain rule.
4. Confirm Live app access reads Only people added and each person is listed under Add app users.
5. Use Copy app link and send the link to the recipients yourself. Saving access does not send an invitation or notification email.
6. Have a recipient open the link and complete the sign-in flow offered by Topline using the approved email. External viewer sign-in requires a verified email and returns the person to the live app.
7. Test both an approved viewer and an unrelated account in separate browser sessions. The unrelated account must have neither a viewer grant nor existing Topline collaboration access.

Adding an app user to an Anyone with the link app switches it to Only people added and requires sign-in. A viewer grant does not enroll that person as a Topline company member or grant workspace, draft, version-history, editing, publishing, or scheduling access. The available sign-in methods depend on the account's identity setup; the approved email still determines access.

Existing owners and authorized Topline collaborators keep their independent artifact access. A live-app allowlist does not revoke those grants. Test external access with an account that is not already a collaborator.

Authenticated method 2: share with Topline teammates

Use this method for internal review or collaboration. It grants more than a live-only viewer link.

1. Open Topline access.
2. Type the person's email in Add people (or pick a suggested teammate), choose Viewer in Role for read-only review, and select Share. Choose Editor only when the person should change the artifact. Pending teammates can be added and see the artifact after their first sign-in. Only active members of your Topline company can be added. If the email is not a member, is archived, or has Chat only access, the drawer explains why and what to do: a workspace admin adds the person, restores them, or switches them to Topline workspace access in Account > Team Members > Manage (which sends their invitation). After they sign in once, share again. Admins get Open Team Members, or Manage with the person's email, as a direct link. When the app is live (or, for other artifacts, always), the drawer also offers Add as app user (or Add as link viewer) as a live-only alternative; that never grants access inside Topline.
3. Send the artifact's Topline page link. The person signs in to your Topline company and opens the artifact; an authorized teammate can also use the deployed app's Live route. Copy Topline link copies the artifact's Topline page link.
4. For several artifacts in one workspace, use workspace Sharing & access and grant Viewer or Editor there instead. Confirm that access to every contained artifact is intended.

Collaboration roles apply inside Topline:

• Viewer can open the shared artifact and, for artifact apps, review the current draft and immutable versions but cannot edit, publish, share, or schedule.
• Editor can use write-capable artifact controls, while owner-only sharing, workspace visibility, and deletion remain restricted.
• Direct workspace membership can grant corresponding workspace artifact access while membership remains active.
• People who do not own the artifact see a read-only Topline access view with their own role and the owner. Company admins who maintain an artifact they do not own also see who has direct access and whether a published link is active (and how many approved viewer emails it has). Only the owner can change sharing.

People with access in Topline access lists the owner, direct collaborators, and people with access through the workspace (labeled Via followed by the workspace name). Each direct person has a role dropdown that changes their role or, with Remove access, removes their direct grant. Everyone else at your company sets company-wide access to Restricted or Can view. Owners also see Scope access, and About Topline access explains each role.

The strongest applicable collaboration role wins. A direct Viewer grant does not reduce an inherited Editor grant. Removing a direct grant does not remove workspace, company-wide, or scope access. Workspace sharing does not share private conversations, and saving a grant sends no notification email.

Some existing published links show Anyone signed in to Topline rather than Only people added. That is a sign-in policy without a named external-viewer list; it should not be used as proof that access is limited to a few people. The Live app access choices add specific people or allow anyone. For an internal-only workflow, grant collaboration access and use the Topline artifact/Live route. For selected external viewers, use method 1.

Save the address, verify access, or revoke sharing

A hosted app shows its main address as a chip under the artifact title. Select it, or See all N addresses / Manage addresses in App access, to open App addresses. Every listed address opens the same live version and follows App access. To change the Topline address, select Edit, enter an optional Site name and a Page name, review the preview, and select Save address. Use Add address for another Topline site name or a Company website. Address links open in a new tab, and each row has a copy button. Claiming an address does not deploy or publish a draft and does not change who can use the app.

Published artifact apps can use a clean address on any company domain connected under Account > Domains. The workspace default is only the initial choice; an artifact owner can choose another connected domain and path. Select Remove on the Company website row in App addresses to move the app back to its Topline address, and move every artifact off a domain before removing the domain itself. Protected viewers still sign in through Topline and return to the customer URL. See Company domains for artifact apps.

To revoke a specific external viewer, select Remove access beside their email under Add app users in App access. Removing the last app user turns off live app access; it does not make the app public. Setting Live app access to Off and confirming Turn off live app access disables the outside link for everyone while preserving Topline collaboration grants and the deployed live version. Revoking internal access requires removing the applicable direct, workspace, company-wide, or scope grants separately.

After a content update, deploy and validate the new draft, publish that reviewed version live, and recheck the existing saved link and audience. Changing the address or viewer list alone does not publish the content update.

For documents, reports, and other non-app artifacts, open Link access. Set Published link access, add specific people under Add link viewers, or choose Anyone with the link for public delivery. Custom URL and embed holds the custom /s/ URL and embed code, and Copy link copies the published link. These links open the published read-only viewer; add people as Viewer in Topline access for draft review.

Never use public access for tenant-private data, credentials, raw PII, or an unreviewed draft.

Troubleshoot publishing and authenticated access

• Not live / publish a live version first: a deployed draft or a claimed app address is insufficient. Return to the artifact, open App access > Publishing, resolve the blockers listed under Publishing details, and publish the reviewed version live.
• Sharing controls unavailable: confirm you are the artifact owner. Editor access alone does not grant owner-only sharing controls; other people see a read-only Topline access view.
• Viewer received no invitation: access changes send no email. Copy the saved app link and send it yourself.
• Sign-in succeeds but the viewer is denied: check the exact approved email, including aliases, and complete email verification when requested. Reopen the saved app link using that identity. For internal access, confirm current company membership and the artifact or workspace grant.
• The owner can open it, but the recipient cannot: the owner has independent collaboration access. Test the recipient's link and account in a separate browser session.
• Everyone can still open it: confirm Live app access reads Only people added, rather than Anyone with the link. Reload after a failed save and test a signed-out session and an unrelated account.
• A removed person still has access: check their remaining direct, workspace, company-wide, and scope grants. Removing one grant does not remove the others.
• The link shows an older app: check the live version; a newer draft is not visible through the live link until published.
• Custom URL fails: use the saved Topline address to isolate an address issue. A company domain must show Connected before its URL is ready. Follow the domain troubleshooting guide.

Manage assets

Uploads accept PNG, JPEG, WebP, GIF, PDF, plain text, Markdown, CSV, JSON, DOCX, XLSX, and ZIP files. Images are limited to 10 MiB and 25 million pixels; other files are limited to 25 MiB. Topline verifies the declared type against the file content, so renaming an unsupported file does not make it uploadable.

In Assets:

1. choose All assets, Unfiled, or a folder;
2. search by file or folder name;
3. create a folder or upload approved files;
4. preview supported content and edit descriptive metadata;
5. copy the stable asset reference for another Topline workflow;
6. cut and paste an asset into another folder when reorganizing; and
7. download or delete only after checking active consumers.

A folder must be empty before deletion. Failed upload, move, metadata save, or delete operations preserve the existing asset and show a recoverable error. Brand logos and favicons can be selected from this library, but changing a brand asset does not automatically update a separately deployed customer runtime.

Storybook and feedback

Storybook at /storybook owns visual drafting and review. Keep the task in its originating Storybook conversation, inspect the rendered result and validation, then publish only the approved draft. Restore the previous published version when rollback is required.

Feedback at /feedback accepts a bounded bug, polish, or feature report and optional images. It queues a coding task; it does not itself merge or deploy a fix. Submit once, preserve the returned task, and answer its attention items instead of creating duplicates.

Automation and MCP

An artifact schedule repeats the saved refresh or supported run under its existing authority. Confirm the target, timezone, cadence, next run, and last outcome before enabling it. App-managed schedules are changed through the app manifest rather than the generic schedule editor.

Build MCP supports private artifact build, inspection, validation, deployment, logs, and handoff. Live promotion remains an operator action. Workspace MCP exposes only permission-filtered context and reviewed knowledge operations.

Errors and recovery

• Artifact missing: confirm tenant, workspace membership, direct share, and whether the requested state is draft, version, or live.
• Draft deploy failed: preserve the exact version and logs, fix the narrow source or configuration issue, then deploy a new reviewed version.
• Live route failed: restore the previous reviewed live version when safe and investigate without promoting an unchanged retry.
• Move failed: the item stays in its prior workspace and remains selected when recovery is possible.
• Share failed: do not assume partial access; reload the authoritative people and general-access state.
• Asset upload failed: keep the source file, verify it is one of the listed types and within the applicable byte and pixel limits, then retry only after the reported format, authorization, or storage issue is corrected.

Enablement and smoke check

Use a non-sensitive test workspace and artifact:

1. create the workspace and one thread;
2. save and file an output;
3. upload and reference a small asset;
4. validate and deploy a private artifact draft;
5. verify a named viewer can read but not edit;
6. promote and verify the live viewer route separately;
7. archive and restore the workspace; and
8. verify permanent deletion remains blocked while dependencies exist.

Current limitations

Supported renderers, artifact app runtimes, share modes, schedules, and MCP connections vary by tenant and artifact kind. Public and embedded links expose only live content. Deleting a workspace, artifact, asset, schedule, or connection does not erase historical audit records.