Pending Writes
What this is
A Pending Write is a Protege-authored change that is waiting for human review before it is applied in Hookshot™. Pending writes are created when the write policy for a project or Protege requires approval.
When to use it
Use this page when you need to:
Review changes a Protege wants to make
Approve, reject, or edit a pending change
Understand what happens when a pending write goes stale
What you need first
A workspace with Proteges that write to the Work Hub under an approval-required policy
Permission to review pending writes (workspace owner, admin, or team lead)
Steps
1. Find pending writes
Open Work Hub → Decisions to see pending writes awaiting review.
Each pending write shows:
The Protege that authored it
The target task and project
The operation type (create, update, comment, etc.)
Whether the write will sync to an external provider (Asana or Jira)
The policy reasons why approval was required
2. Review the change
Open a pending write to see:
Before snapshot: The current state of the task before the change
After snapshot: What the task will look like if the change is applied
Edited payload: If you modify the change before approving, the edited version appears here
Always review both the before and after snapshots before approving. The Protege may have made assumptions about the current state that are no longer accurate.
3. Approve, reject, or edit
Approve
The change is applied to the task. If the project has provider sync enabled, the change is also pushed to the external provider.
Reject
The change is discarded. You can optionally provide a reason.
Edit then approve
You modify the payload before approval. The edited version is applied instead of the original.
4. Handle stale writes
A pending write becomes stale if the underlying task has changed since the write was created. Stale writes are flagged because the before snapshot no longer matches the current state of the task.
When you encounter a stale write:
Review whether the change is still appropriate given the new task state
If it is still valid, approve it (the system will apply it against the current state)
If it is no longer valid, reject it
5. Reopen a rejected write
If you rejected a write by mistake, you can reopen it for re-review. The write returns to pending status and can be approved or rejected again.
6. Understand write policy and pending writes
Pending writes are created when the write policy evaluates to approval_required. The policy is determined by four sources:
Work Hub default — the global setting
Project policy — per-project override
Protege policy — per-Protege setting
Sensitivity — the operation type
If any source says approval_required, a pending write is created instead of applying the change directly.
Operations that always require approval:
Approval-sensitive work
Decision requests
Provider sync (writes that will push to Asana or Jira)
7. Review provider impact
When a pending write targets a project that has provider sync enabled, approving the write will also push the change to the external provider. The pending write view shows whether the write has provider impact so you can consider the external consequences before approving.
How to verify
Pending writes appear for Protege changes that require approval
Approved writes are applied to tasks and reflected in the task detail view
Rejected writes are discarded and not applied
Stale writes are flagged with a clear indicator
Provider-synced writes update the external provider after approval
Common failures
Approving a write without checking the after snapshot
Ignoring stale indicators when the task has changed
Approving a provider-projected write without considering the external impact
Rejecting a valid write that could have been edited instead
Assuming direct mode is safe for all projects without reviewing the operations
Next step
Last updated
Was this helpful?