Skip to main content
Manual review covers business semantics, environmental impact, and exception conditions that automated rules cannot determine completely. The approval decision should be grounded in review results and validation evidence, not used as a substitute for them.
A typical flow in the interface is: after automated review completes, the submitter clicks Submit for review to route the ticket to approvers; the approver reviews the approval timeline on the “Approval history” tab and makes the final decision; execution after approval is recorded on the “Execution records” tab. Built-in approval, separation of duties, and workflow states depend on PawSQL edition, licensing, and organization configuration. If these capabilities are not available, complete the approval in your ticketing system and link the PawSQL ticket or report.

​
Goal

Add human judgment, exception approval, and an auditable release decision on top of automated SQL review.

​
Roles and responsibilities

Roles may overlap in smaller teams. For a high-risk production change, avoid allowing the submitter to provide the only approval.

​
Evidence package

Prepare the following before requesting manual review:
  • the PawSQL review ticket or report;
  • target database, version, schema, and environment;
  • SQL changes and their business purpose;
  • unresolved findings and acceptance rationale;
  • expected impact, data volume, and deployment window;
  • test results and relevant performance evidence;
  • backup, monitoring, stop conditions, and rollback plan;
  • related requirement, defect, or change ticket.

​
Review workflow

1

Verify review completeness

Confirm that all statements were parsed and that the policy and workspace represent the target environment.
2

Evaluate unresolved findings

Decide whether each risk was removed, is acceptable with controls, or requires more evidence.
3

Check release readiness

Review execution identity, timing, backups, monitoring, rollback, and communication arrangements.
4

Issue a decision

Approve, return for changes, or approve with conditions according to the reviewer’s authority. State the rationale.
5

Preserve the record

Capture the reviewer, timestamp, decision, comments, attachments, and linked work item.

​
Decision model

Actual state names depend on the PawSQL version or external workflow.

​
Write a useful approval record

A defensible approval explains why the decision was made and under what conditions. Include:
  • which findings were resolved or accepted;
  • the SQL, environment, and validity period covered by an exception;
  • prerequisites that must be completed before execution;
  • monitoring signals, stop conditions, and rollback owner;
  • whether post-deployment verification is required.
Avoid comments such as “approved” or “confirmed” with no decision rationale.

​
Exceptions and exemptions

When you accept a finding without remediation, keep the exception as narrow as possible (specific SQL, rule, project, environment, and validity period) and record:
  • the rationale and business necessity;
  • the risk owner and approver;
  • affected objects and expected data volume;
  • compensating controls such as throttling, monitoring, backup, or rollback;
  • deployment window, monitoring signals, and stop conditions;
  • an expiration date to prevent permanent bypasses.
Do not weaken a global policy to accommodate a single case. If your PawSQL edition supports suppression, exemption, or approval, apply it to the narrowest scope and retain the audit trail.
If the SQL, review policy, workspace, or execution environment changes materially after approval, the previous decision may no longer apply. Run the review again and repeat the required approval process.

​
Permission and audit guidance

  • Separate submission, review, approval, and policy-administration permissions by role.
  • Prevent approvers from silently changing the submitted SQL or generated results.
  • Record workflow transitions, actors, and timestamps.
  • Revisit long-lived exceptions on a defined schedule.
  • Apply stronger authorization to high-risk production changes.

​
Expected Result

The ticket records a grounded approve, return, or conditional decision with rationale, evidence, and an audit trail.

​
Verification

Confirm the approval record states the decision rationale and covered scope, and that the approval timeline and execution records reflect the outcome.

​
Next step

After disposition, use History, Reports, and Export to retain and retrieve the decision record.