Document card and reading a version
The document card is the workspace for one document. It brings together context, current status, files, versions, external access, signing, exchange, and permissions. Actions depend on your permissions and document policy; a disabled action is not a promise of an alternative workaround.
Screen map
Screen map — conceptual flow, not a UI screenshot or evidence.
The header shows type, current version, update date, title, and status. A business document may also show its next step—prepare a version, open it, send it for signature, or refresh exchange. Follow subscribes you to document changes.
The main blocks are:
- Context: linked company, counterparty, legal entity, and client-extranet visibility;
- Files and versions: primary file and package materials with role, type, size, view, and download;
- Signatures: active request, signers, provider, deadline, link, and cancellation where allowed;
- Access: owner, read/write mode, external visibility, classification, and legal hold;
- Document history: revisions, publications, and signature requests;
- Next step, quick actions, and EDI only when the relevant data or capability exists.
Reading files
Reading files — conceptual flow, not a UI screenshot or evidence.
Use Open to view a file in a new tab or Download to save it. The card opens the selected current revision; if one is not yet defined, it uses an available latest revision. With multiple files, roles distinguish the primary file from package materials, and the card can download the package.
Long technical filenames are truncated to one line while the full value remains available on hover. Verify the file contents and revision before sending it outside; the displayed filename alone is not proof of freshness.
The list shows at most four files at once; additional files appear as “+N more”. When there is more than one file, you can download the whole package. If package assembly fails, the card shows an inline download error; check access and file selection before retrying.
Revisions and draft
Revisions and draft — conceptual flow, not a UI screenshot or evidence.
A revision can carry source, rendered, and signed files. Keep older revisions when they support approval or signature history. A saved Rich Text draft can be previewed and turned into a new revision with Create revision from draft. Create, review, and then publish or sign the resulting revision.
When the draft changed after the latest revision, the card warns that view, download, and signing still use the latest created revision. Wait for the draft preview (retry if it fails), then use Create revision from draft to include the new content.
Context, access, and privacy
Context, access, and privacy — conceptual flow, not a UI screenshot or evidence.
The card either shows the linked context or explicitly says that no current context exists. Re-linking and unlinking require write access; external EDI documents can be restricted by access policy. Access shows owner, read-only or editable mode, extranet visibility, classification, and legal hold.
In read-only mode, editing, publishing, signing, and integration actions are hidden; there is no client-side bypass. If no revision exists yet, the card shows a no-current-file state instead of file actions.
Linking and moving a document
Linking and moving a document — conceptual flow, not a UI screenshot or evidence.
In Add existing document (or Move document for an already linked file), search and choose a client, client project, legal entity, opportunity, task, company, or contact. Search is delayed and may return a partial result: “Results may be incomplete” means use Try again, not that the list is empty. After you select a target, the portal checks whether the link is allowed; saving stays disabled while it is pending or denied. If target search fails, retry it and do not try to bypass the denial another way.
Do not put personal, financial, or internal comments in a public description. Before creating a link, verify recipient, context, and included files.
Publication and signing
Publication and signing — conceptual flow, not a UI screenshot or evidence.
View publication and a signature request are separate operations. A publication may be view-only or external signing, with access policy, expiry, and an opening limit. A request identifies revision, scenario, signers, provider, and an optional deadline. Client-extranet signing may resolve a signer from CRM; public signing requires an external signer.
Protected link access allows anyone who has the link, while Recipient only requires that recipient to confirm ownership of the email address. Expiry and maximum view count still limit access after a link is issued.
The card reports signer and request statuses. Never share a personal signer link with another person. Cancel active requests and close publications when access is no longer needed. See Signature and external access.
EDI, inbound exchange, and errors
EDI, inbound exchange, and errors — conceptual flow, not a UI screenshot or evidence.
For externally managed documents, the human-facing status comes from exchange status. The EDI block may show provider, lifecycle, clearance, rejection code, submission ID, and a verification link. Open EDI and Refresh appear only when the action is available.
Inbound candidates must be matched, checked for duplicates, and then created or linked; one file is not proof that an exchange is complete. If loading fails, use the refresh action and keep the error context. “Document unavailable” means missing or inaccessible, not necessarily deleted.
When a package or document is republished, an unchanged published revision stays pinned. If access policy does not allow an action, the card hides the button or shows the reason; a missing button is not an invitation to use another route.
Errors and unavailable actions
Errors and unavailable actions — conceptual flow, not a UI screenshot or evidence.
The first load uses a waiting state. If a refresh fails after the card is visible, existing data remains on screen with the error and a Refresh action. “Document unavailable” means missing or inaccessible, not necessarily deleted. If an action is disabled, check the current permission, document status, and reason shown in the card before trying again. Do not retry a blocked publication, signature, or EDI action blindly.
In the current related-documents bundle, an error can contain technical server or transport text. Do not treat it as a readable reason, forward it, or place it in a screenshot/evidence: it can contain identifiers or other protected data. Close or refresh the card; if no safe localized explanation appears, give the owner only the route, time, and action taken — not the error contents.
Checklist
Checklist — conceptual flow, not a UI screenshot or evidence.
- Confirm the card and linked context.
- Confirm that the current revision contains the intended file.
- Confirm owner, next step, and permissions.
- Restrict external access to the right recipient and expiry.
- Confirm signing scenario and signers.
- Preserve history and older revisions.
Related pages
Related pages — conceptual flow, not a UI screenshot or evidence.