Set the final version
Finish the review and retain the exact version that will be sent for signature.
Contract signing workflow
Send a contract for signature, then keep the audit trail
Signing is the last part of the contract process, not a separate filing system. Send the final document from its project and keep the result and signing activity together.
Start a signing workspaceWhat this workflow is for
Signing begins after the terms are settled.
Use contract signing when the document has reached its final form and needs the right people to complete it. The signing request should not become a substitute for review or approval. It is the execution stage: recipients receive the agreed contract, the sender can follow the request status, and the completed record stays with the project that produced it.
That connection is useful long after the request is complete. A team member can see the final contract alongside the proposal, earlier review versions and signing history rather than trying to reconstruct the agreement from a separate e-signature inbox.
The workflow
One document, every next step.
- 01
Your team - 02
Your team Request signatures
Choose the recipients and send the signature request from the document.
- 03
Your team Track the signing status
See whether recipients have opened, signed or need a reminder from the document record.
- 04
Your team Keep the completed record
The signed outcome and audit trail remain with the contract in its project.
Choose the right next step
Use signing when the document is ready to execute.
The terms have been agreed
The file sent for signature should be the settled version. If a recipient still needs to negotiate language, return to contract review first.
There are known recipients
A signing request needs clear recipients and a deliberate final document. This makes status meaningful: it refers to a specific person acting on a specific agreement.
The result needs to be retained
Use the workflow when the completed contract and its request history need to remain accessible to the client project, not only to the person who sent it.
Why keep it together
The file is the shared context.
- The final contract is not detached from the approval work that preceded it.
- Signing status is visible next to the document.
- The audit history is retained with the completed record.
Keep the process clear
Send a signature request with confidence.
Confirm the final file first
Check that the contract is the intended final version before adding recipients. The version history helps the team distinguish the agreement from the drafts that led to it.
Treat status as operational context
Opened, signed and incomplete states help the document owner know what should happen next. They are most useful when the request stays beside the agreement itself.
Keep the completed agreement discoverable
When signing is complete, leave the final document and activity in the client project. The next person should be able to find both without relying on an individual inbox.
Questions, answered
Contract signing questions
Should we send a contract for signature before review is complete?
No. Send the final version for signature after the review and any approval stage have settled the terms.
Can we see whether a recipient has opened the request?
Yes. The document record can show the signing request status so the sender can follow what has happened without separating the request from the contract.
Where does the signed contract live?
The completed agreement remains in its client project with its document history and signing activity, instead of being detached into a separate filing system.
What if the agreement changes after a signing request is sent?
Prepare a revised final version and use the appropriate document workflow before sending a new request. A signature should always relate to the exact agreement the parties intend to execute.
Start the workflow
Give the next document a place to go.
Free to start with one project and no card needed.
Start a signing workspace