Every pipeline report I review has the same weakness. The stages are stale. Deals sit in "Proposal Sent" two days after the contract was signed because a rep forgot to drag a card across the board. It is a small omission, but it makes your forecast wrong, your velocity numbers unreliable, and your pipeline reviews a guessing game.
There is a straightforward fix. Instead of relying on humans to update deal stages, you let the document itself trigger the move. When a proposal is sent, the deal advances to "Proposal Sent." When a signature request goes out, it moves to "Contract Sent." When the document is signed, the deal moves to "Closed Won." No memory required.
In this article I will walk through how to set up deal stage auto-progression in HubSpot using Portant's Document Status property and standard HubSpot workflows. If your pipeline always seems a few days behind reality, this is probably why, and this is the fix.
Why manual deal stage updates fail
Reps are busy. They are on calls, writing emails, following up with buyers. Updating a deal stage is a low-priority task that adds zero value to the sale itself. So it gets skipped, delayed, or done in batch at the end of the week.
The impact is bigger than most leaders realize. If five reps each forget to update three deals per week, that is fifteen deals sitting in the wrong stage at any given time. Your pipeline report tells leadership one story. Reality tells another.
Forecasting depends on stage. If your forecast model weights deals by stage probability, stale stages produce inaccurate numbers. A deal that is actually closed but still shows as "Contract Sent" understates your closed revenue. A deal where the proposal errored out but still shows as "Proposal Sent" overstates your pipeline. Both are bad.
The fix is not more discipline or another Slack reminder. You will never train humans to reliably update a CRM field every time an external event happens. The fix is to remove the manual step entirely and let the event itself trigger the update.
The document lifecycle as a pipeline signal
When you use Portant with HubSpot, every document you generate is saved as its own record, a Custom Object, on the deal. That record carries a property called Document Status, and it updates automatically as the document moves through its lifecycle.
This is the signal your pipeline needs. Instead of asking reps to watch their inbox and then update HubSpot, the Document Status property changes on its own when something real happens. A document is sent. A signature is requested. The document is signed. Something goes wrong. Each of those status changes corresponds to a real moment in the sales process, which means each one can map directly to a deal stage.
I wrote a related piece on how to align deal stages with document types that covers the conceptual mapping between stages and documents. This article goes a step further. It automates that alignment so the pipeline updates itself.
Portant Document Status values
Portant's Document Object tracks nine status values. Here is what each one means and when it applies.
- Pending: The document record has been created but generation has not started yet.
- Draft: The document has been generated but is still in draft state, not yet finalized.
- Approved: The document has been reviewed and approved internally. This applies if you use Portant's approval workflows.
- Sent: The document has been delivered to the recipient.
- Signature Requested: An eSignature request has been sent to the signer or signers.
- Partially Signed: At least one signer has completed their signature, but others remain.
- Signed: All signers have completed their signatures.
- Completed: The document lifecycle is finished, including any post-signature steps.
- Error: Something went wrong during generation, sending, or signing.
Not every deal will pass through all nine statuses. A simple quote might go from Pending to Sent without needing a signature. A contract might pass through Sent, Signature Requested, Partially Signed, Signed, and Completed. The workflows you build should account for the statuses that actually matter in your process.
For full details on how these properties work, see the Portant documentation on triggering HubSpot workflows from document status changes.
Building the workflows
The setup uses HubSpot's standard workflow tool. You will create deal-based workflows that trigger on changes to the Document Status property on the associated Portant Document Object.
Here is the core mapping I recommend for most sales processes.
Workflow 1: Document Sent → Move to "Proposal Sent"
- Go to Automation > Workflows in HubSpot.
- Create a new deal-based workflow.
- Set the enrollment trigger to: Associated Portant Document Object > Document Status is "Sent."
- Add an action: Set deal property > Deal Stage to "Proposal Sent" (or whatever your equivalent stage is).
- Save and turn on.
When Portant delivers a proposal or quote to the buyer, the Document Status changes to "Sent." This workflow catches that change and moves the deal forward automatically.
Workflow 2: Signature Requested → Move to "Contract Sent"
Same structure, different trigger.
- Enrollment trigger: Document Status is "Signature Requested."
- Action: Set deal stage to "Contract Sent."
This covers the moment when the signing process begins. The buyer has received the document with an eSignature request, and the deal stage should reflect that.
Workflow 3: Signed or Completed → Move to "Closed Won"
- Enrollment trigger: Document Status is "Signed" OR "Completed."
- Action: Set deal stage to "Closed Won."
You can use either "Signed" or "Completed" depending on how your process works. If you need all post-signature steps to finish before closing the deal, trigger on "Completed." If the final signature is your close event, trigger on "Signed."
Workflow 4: Error → Notify the deal owner
- Enrollment trigger: Document Status is "Error."
- Action: Send an internal notification to the deal owner with a message like: "A document on [Deal Name] has an error. Please check the document and re-send if needed."
This one matters because error states are invisible without an alert. A rep might not notice that a contract failed to generate or that a signature request bounced. An immediate notification prevents deals from stalling silently.
Alternative: one workflow with branches
If you prefer fewer workflows to manage, you can create a single deal-based workflow with an If/Then branch that checks the Document Status value and routes to the appropriate action. The logic is identical, the organization is just different. I usually start with separate workflows because they are easier to debug, then consolidate later if the team wants a cleaner view.
Adding Deal Tags for pipeline visibility
Deal Tags are color-coded labels that appear on deal cards in HubSpot's board view. They give reps and managers a fast visual indicator when scanning the pipeline without opening each deal.
Portant lets you add Deal Tags based on Document Status, so your pipeline board shows at a glance where each deal stands in the document lifecycle. For example:
- A green tag for "Signed" deals
- A yellow tag for "Signature Requested" deals
- A red tag for "Error" deals
- A blue tag for "Sent" deals
This is especially useful in pipeline reviews. Instead of clicking into each deal to check document progress, managers can scan the board and immediately spot deals that need attention, whether that is a stuck signature or an error that slipped through.
For setup instructions, see the Portant guide on adding Deal Tags using Document Statuses.
Edge cases to plan for
No automation works perfectly on day one. Here are the situations I see trip teams up, and how to handle each one.
Multiple documents per deal
A single deal might have a quote, a proposal, and a contract, each with its own Document Status. If the quote is "Completed" but the contract is "Pending," which status should drive the deal stage?
My recommendation: use the most recent document's status as the primary signal. In your workflow enrollment, you can filter on the document template or name if you use consistent naming conventions. This takes some testing, but getting it right prevents a completed quote from prematurely closing the deal when the contract has not even been sent yet.
Re-sent proposals
If a rep re-sends a proposal because the buyer requested changes, the Document Status will cycle through its values again. Your workflow should handle re-enrollment so the deal stage updates correctly when a new "Sent" status appears on a different document.
Be aware that this can move a deal backward in the pipeline. If a new proposal is sent after a contract was already in progress, the deal might revert to "Proposal Sent." Consider whether your workflows should only move stages forward and never backward. For most teams, I recommend forward-only logic with a separate, deliberate workflow for any backward movement.
Error states
An error does not mean the deal is lost. It means something technical went wrong, like a template merge failure or a signing service timeout. The notification workflow in Workflow 4 is your safety net here. Make sure the notification includes enough context for the rep to act: the deal name, the document name, and a pointer to check the status in Portant.
Partially Signed documents
For multi-signer contracts, "Partially Signed" is a useful intermediate status. You might not need a separate deal stage for it, but a Deal Tag such as "Awaiting signatures" helps managers track which contracts are in progress versus which are stuck waiting on a specific signer.
What this does for pipeline reporting
When deal stages update automatically based on real document events, three things improve.
Forecast accuracy. Stages reflect what actually happened, not what a rep remembered to log. If your forecasting model uses stage probabilities, those probabilities are now based on reality instead of a best guess from last Friday's data cleanup.
Pipeline velocity. Time-in-stage metrics become meaningful. You can measure how long it actually takes from "Proposal Sent" to "Contract Sent" because both transitions are tied to document events, not manual clicks. That gives you real data on where deals slow down.
Pipeline hygiene. Stale deals become easier to spot. If a deal has been in "Contract Sent" for two weeks and the Document Status still shows "Signature Requested," something is wrong with the deal, not with the data. Managers can focus their pipeline reviews on coaching instead of data entry audits.
This is the kind of ops design that compounds. You build it once, and every deal that runs through the pipeline gets a more accurate stage without anyone thinking about it.
Getting started
If you are already using Portant with HubSpot, the Document Status property is already on your document records. Start with the four core workflows I described above. Test them on a handful of deals before rolling them out to the full team.
If you want to go deeper on how stages and documents should connect conceptually, read my earlier piece on mapping deal stages to document types.
And if you are not using Portant yet, the HubSpot integration page covers what it does and how to get set up.
Frequently asked questions
Does this work with any deal pipeline in HubSpot?
Yes. The workflows trigger on the Document Status property of associated Portant Document Objects, which is not tied to a specific pipeline. You can set different stage mappings for different pipelines using workflow branches.
What if my deal stages don't match the examples?
The mapping is entirely flexible. The examples I used ("Proposal Sent," "Contract Sent," "Closed Won") are common labels, but you should map Document Status changes to whatever stages your pipeline actually uses. The important thing is that each status change maps to a meaningful stage transition for your process.
Will this override manual stage changes?
It depends on how you set up the workflows. If a rep manually moves a deal to "Closed Won" before the document is signed, the workflow will not revert it unless you specifically configure it to do so. I recommend building workflows that only move stages forward. If you need backward movement, add it as a separate workflow with extra safeguards and clear documentation for the team.
Can I use this with approval workflows too?
Yes. If your team uses Portant's approval workflow, the Document Status updates to "Approved" after internal review. You can add a workflow that moves the deal to a stage like "Pending Send" or "Ready for Buyer" when that happens. This is useful for teams that need manager sign-off before any proposal goes to a client.
