Guide · Approvals and audit
Operate an approval queue without losing decision context
A practical queue routine for pending proposals, spatial checks, decisions, corrections, conflicts, and partial bulk results.
- Category
- Approvals and audit
- Best for
- Approvers, operations leads, and submission owners
- Reading time
- 5 min read
- Content review
Scope of this guidance
Pole has approval records for named workflows, but this guide does not claim that every edit in the product enters an approval queue. Confirm the workflow in scope before relying on approval evidence.
Step 1 of 4
Triage the pending queue
Start with scope and consequence rather than age alone. Separate estate, plot, reservation, allocation, and correction proposals, then identify items blocked by missing source data or another active decision.
- Filter to the estate, submission type, requester, and pending state that the reviewer owns.
- Identify corrections linked to an earlier rejection and read the prior reason before reviewing the new proposal.
- Leave a conflicted or already-processing item visible instead of submitting a competing decision.
Step 2 of 4
Review the proposal and its evidence
The reviewer should compare current and proposed values, requester context, affected records, and any validation findings. Spatial work also needs explicit source coordinate reference and the applicable containment or overlap result.
- Confirm the requester, submission time, record identity, and stated reason.
- Compare current and proposed fields rather than reviewing a summary alone.
- For geometry changes, inspect source datum and zone, boundary context, and any blocking conflict before deciding.
Step 3 of 4
Make one explainable decision
Approve only a proposal that still satisfies the decision-time checks. Reject with a reason that tells the submission owner what must change. A decision lock or stale-state conflict is a signal to reload, not a reason to bypass the workflow.
- Recheck that the item is still pending and that the reviewer is authorized for its company and action.
- State a useful rejection reason when the proposal cannot be accepted.
- After a decision, verify the resulting record state rather than assuming the queue result applied every downstream change.
Step 4 of 4
Handle corrections and partial outcomes
A rejected proposal should remain linked to its correction. Bulk approval can produce mixed outcomes, so a single success message is not enough to explain which records changed.
- Keep the original rejected proposal, rejection reason, and correction lineage together.
- Group bulk results into completed, rejected, conflicted, and unchanged items.
- Retry only after the source data or conflict that blocked the item has been resolved.
Final checks
Confirm these points before treating the workflow review as complete.
- The reviewer can identify the requester, record, proposal, and consequence.
- Current and proposed values are compared directly.
- Rejections provide a usable correction reason.
- Mixed bulk outcomes remain itemized and recoverable.
Continue the review
Continue evaluating this workflow
Review the related Pole workflow, then request organization access when your organization is ready to begin the application. Access is reviewed by Platform and is not created immediately.