These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- E-signature Platform
- Features
- Follow-up and corrections
Follow-up and corrections
Assign signing exceptions and retain the earlier decision trail.
OverviewMy Follow-Up Actions×
E-signature Platform · Follow-up and corrections
New
My Follow-Up Actions
Follow up actions
| Source | Title | Due date | Status | Resolution | |
|---|---|---|---|---|---|
| SP-25951 | Open fua-132 | 26 Oct | Open | RSL-986 | |
| SP-94027 | In progress fua-892 | 22 Oct | In progress | RSL-206 | |
| SP-37634 | Completed fua-936 | 17 Oct | Completed | RSL-426 | |
| SP-40381 | Cancelled fua-291 | 04 Oct | Open | RSL-470 | |
| SP-18234 | Open fua-443 | 14 Oct | In progress | RSL-293 |
6 of 6 records
Open fua-132Follow up actions · FUA-34511
OpenSourceSP-25951
Due date26 Oct
ResolutionRSL-986
What you can do
Give every exception an owner
A follow-up action belongs to a packet and names a person responsible for the next step. Its due date and status make unfinished work visible; its resolution and completion time explain how it ended. State history records the earlier and later packet status, source revision, operation key, actor and reason. Together, these records help the team correct an executed revision without erasing the event and decision that came before it.
How the work is organized
- Assignment. Name the person responsible for the open action and its due date.
- Resolution. Record what was done before marking an action completed.
- History. Preserve the old revision and explain the successor change.
What to agree during setup
Agree which exceptions need a follow-up action and who may close it. Decide how an executed packet is superseded, including the reason, signer event and fresh review. Keep prior successful operation steps and confirmed evidence available for investigation. A new revision should be linked to the original work by packet identity and explained in the change history.
Check the handoff on an actual case
A signer’s name is found to be wrong after an executed packet is reviewed. The owner records the reason and prepares a successor revision. The earlier signed event and receipt stay in the record; a compensating signer event explains the correction. A follow-up owner checks the new evidence and records the resolution. The reviewer then examines the changed revision before any further sending. A later audit can follow both decisions and see why the packet moved forward.
The handoff should be checked on a real packet, not just on a status label. Open the linked record and compare the people, revision and provider evidence behind the decision. If the record is returned or uncertain, keep it visible to the person responsible for the next action. The next team should be able to explain what was received, what was accepted and why the packet changed state.
The action should identify the person who will verify the correction, not only the person who noticed the problem. Keep its due date and status current while the owner prepares the successor revision. Compare the new signer event and review decision with the earlier signed evidence before closing the action. The resolution should explain what changed and which provider result was checked. State history gives the team a way to trace the transition, while the retained prior event and operation steps show what actually happened on the earlier revision.
What your team sees
- Open Follow-Up Actions — Outstanding corrections with owners and due dates.
- My Follow-Up Actions — The assigned person’s current exception work.
Follow the work through
Follow packet preparation and signer verification.
What it keeps track of
Data model- Follow up actions
- A task assigned after a review, used by the team to track who must fix or address something and by when.
- State history
- A record of a status change, used by the team to see how and when something moved from one state to another.
- Signature packets
- A batch of documents sent out for signature, used by the team to track who's signed and whether it's complete.
- Signer events
- An update on a signer's progress on a document, used by the team to track how far a signature request has gotten.
- Review decisions
- A ruling made on a submitted item, used by the team to record whether it was approved or rejected and why.
- People
- A person who works with or is tracked by the platform, used by the team to manage who does what.
Who uses it
Permissions- Follow-up Owner
- , Packet Owner, Signature Reviewer.
Set up E-signature Platform your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.