Open a single asset on the company-specific route pattern /companies/[id]/assets/[assetId].

Use this article when you need help with this topic in LenGrowth.

The top of the page shows a back link labeled Back to Assets, the asset name, the current status badge, the asset type, the version number, and the last updated date.

The visible status labels on this page are:

That status is important because a lot of the controls on the page change based on it. A verified asset can be shared as a live link. A draft or review-requested asset stays in a more cautious workflow.

The page also shows collaboration presence, so the customer can tell whether anyone else is working in the same document.

The editor area is protected by a lock flow. The user can see one of three states:

When the asset is locked by the current user, the page tells them they have exclusive editing rights and reminds them to save their changes. When it is locked by someone else, the page switches to read-only mode and explains that the document is currently being edited. The button in the unlocked state says Start Editing.

This is worth explaining carefully in support because a locked asset is not broken. It is intentionally preventing two people from editing the same content at the same time.

The visibility card is labeled Visibility, and the main prompt is Who can access this asset?

The visible access choices are:

The card shows the current access state and explains what it means. If the asset is role restricted, the user can select from:

If the asset is tied to task participants, the page reminds the user that task-bound access should be managed from the task flow so the rule stays tied to the work item instead of being copied around by hand.

This is one of the places where the page is deliberately precise. Do not describe it as a generic public/private toggle. It is a real visibility model with company, role, private, and task-bound access.

The comments panel supports threaded comments and anchored comments. The UI can show selected text and line references, which is helpful when someone wants to comment on a specific part of the asset.

The panel is built for discussion, not just note-taking. Users can:

Linked tasks are shown in their own card labeled Linked tasks. The subtext says these are tasks that reused or were generated from the asset. That matters because it gives the customer a traceable bridge between a document and the work that produced it.

If a task was linked back to the asset after completion, the panel says so. That is a good support clue when someone is trying to understand where a deliverable came from.

The sharing card is titled External sharing and explains that it is for Live client portals or fixed snapshots.

The two share modes are:

Live links always open the latest verified version and are only available after the asset is verified. Snapshot links freeze the content to one version for a fixed deliverable trail.

The share panel also includes:

The export flow sits in the top-right action area under Export. The visible export choices are:

That is the exact language you should use with a customer. If they ask whether the asset can be exported, the answer is yes, and those are the formats the page shows.

Some asset types can be regenerated from the detail page. The button says Regenerate, and it only appears for Business Profile and Custom Asset.

That detail matters. If the asset is a different type, do not tell the customer that every asset can be regenerated from the detail page the same way.

The delete action in the top-right is really an archive flow. The confirmation says Archive this asset? It will be removed from the active hub. That is the safer way to describe the action: it moves the asset out of the active hub rather than acting like a normal content edit.

The page can show a Stale warning banner when an asset has become outdated. In that case, the refresh action is available for Business Profile or Custom Asset, which is why the page should not be described as if every stale asset has the same recovery button.

The page can also show an Evidence conflict detected banner. That banner appears when uploaded evidence contradicts a verified asset. The user must choose whether to trust the Verified asset or the Uploaded document, or they can Dismiss for now.

This is one of the strongest signals in the asset workflow: the product is explicitly asking the user to resolve evidence, not silently overwrite it. Support should preserve that framing.

At the bottom of the sidebar, the Metadata card shows three useful labels:

The page also lets the user copy the storage path. This is mostly a support and debugging aid, not a daily end-user feature, but it can be useful when someone needs to explain where a document came from.

Use this page when the customer wants to:

If the customer only wants the library view, send them back to /companies/[id]/assets. If they need company-wide settings or teammate management, this is not the right page.

The right side of the page includes a card titled Verification Status with the subtitle Quality Control Gate.

The three primary states are:

The verified state exposes:

The review flow exposes the buttons:

If the current user cannot verify, the page keeps them in the request flow instead of pretending the document is ready. That is why support should not promise that every user can mark every asset verified.

The verification panel also explains the meaning clearly: a verified asset becomes a source of truth and will be used as context for future AI task recommendations and strategy generation. That is the correct product story to use when someone asks why verification matters.