NetStacksNetStacks
Contact SalesDownload

MOP Approvals

Enterprise

Submit a Method of Procedure for review and have a reviewer approve or reject it before execution, with reviewer, timestamp, and comment recorded for audit.

Overview

The MOP approval workflow adds a human review gate in front of execution. A Method of Procedure (MOP) is authored as a draft, submitted for review, and then approved or rejected by a reviewer. Only an approved MOP should be run against production devices.

Enterprise feature

MOP review and approval is part of the NetStacks Controller (enterprise mode). The Terminal pushes MOP plans to the Controller, where they are stored, versioned, and reviewed. Standalone Terminal use does not include the approval workflow.

The review workflow provides:

  • A single approve/reject decision — a reviewer evaluates the procedure and approves or rejects it in one action.
  • Review comments — the reviewer attaches a comment explaining the decision. It is stored on the MOP record.
  • Audit trail — the reviewer, decision timestamp, and comment are recorded as reviewed_by, reviewed_at, and review_comment.
  • Versioned revisions — a rejected MOP is revised and resubmitted as a new revision within the same lineage, preserving the full history.
  • Change-management metadata — an optional risk_level and change_ticket link the MOP to your ITSM process for context during review.
What is not configurable

The current review model is a single approve-or-reject decision. There are no multi-approver thresholds, approver groups, per-risk approval policies, or approval-withdrawal actions in the product. If you need those controls, enforce them through your reviewer roles and external change process.

MOP Lifecycle

A MOP plan moves through a small set of review states. These describe the plan — the reusable, versioned procedure definition — not a running execution.

Plan statusMeaning
draftBeing authored or edited. Editable and deletable. Not yet submitted for review.
pending_reviewSubmitted for review and awaiting a reviewer's decision.
approvedA reviewer approved it. Ready to be instantiated and executed.
rejectedA reviewer rejected it. The author revises and resubmits as a new revision.
archivedRetired from active use. Kept for historical reference.
Plan status vs. execution status

Approval governs the plan. Running the plan creates a separate execution record with its own status — pending, running, paused, completed, failed, or aborted. Those execution states are not part of the approval state machine. See Task Monitoring for execution tracking.

The Review Workflow

1. Author the MOP

Create the procedure in the Terminal's MOP workspace — the ordered steps (pre-checks, changes, post-checks, rollback), optional risk_level, an optional change_ticket reference such as CHG-3192, and any tags. Pushing the plan to the Controller creates a draft MOP.

2. Submit for review

Submitting the draft moves it to pending_review. This is a one-step transition; the plan is now read-only pending a decision.

# Submit a draft MOP for review (draft -> pending_review)
POST /api/mops/{mop_id}/submit

3. Review the procedure

A reviewer opens the pending_review MOP and inspects the full procedure: every step and command, expected outputs, rollback steps, the declared risk level, and the linked change ticket.

4. Approve or reject

The reviewer submits a single decision. Approving sets the status to approved; rejecting sets it to rejected. In both cases the reviewer identity, timestamp, and comment are stored on the record (reviewed_by, reviewed_at, review_comment).

# Approve a pending MOP
POST /api/mops/{mop_id}/review
{ "approved": true,  "comment": "Steps and rollback verified. Approved." }

# Reject a pending MOP
POST /api/mops/{mop_id}/review
{ "approved": false, "comment": "Add a 'show ip bgp summary' post-check, then resubmit." }
Make the comment count

The comment is the only free-text record of why a decision was made. On rejection, be specific about what to change so the next revision can address it directly. On approval, note what you verified (rollback tested, maintenance window confirmed) for the audit trail.

Who may review is governed by your Controller roles and permissions. Grant the review capability only to users who should authorize changes.

Revisions & Resubmission

There is no "edit and re-approve in place" or withdraw-approval action. The recovery path after a rejection — or any change to a reviewed MOP — is to create a new revision within the same lineage.

  • Every MOP belongs to a lineage identified by mop_lineage_id. The revision field increments as new versions are created in that lineage.
  • To produce a new revision, push the updated plan to the Controller with the existing mop_lineage_id. This creates a fresh draft that carries the lineage forward; the previous revision and its review history are preserved.
  • The new draft is then submitted and reviewed exactly like the first.
# Create a new revision in an existing lineage, then resubmit
POST /api/mops
{
  "mop_lineage_id": "8f1c0a2b-3d4e-5f60-7182-93a4b5c6d7e8",
  "package_data": { "mop": { /* updated steps */ }, "metadata": { /* ... */ } }
}

# The response is a new draft (revision incremented). Submit it for review:
POST /api/mops/{new_mop_id}/submit
Editing and deleting

A MOP can be edited (PUT /api/mops/{id}) only while it is a draft; once submitted it is read-only. Deletion (DELETE /api/mops/{id}) is not gated by status — a MOP can be removed in any state. To change an approved MOP without deleting it, create a new revision so its history is preserved.

API & Record Examples

An approved MOP record

A Controller MOP after approval. The review fields capture the decision; mop_lineage_id and revision track its place in the lineage:

approved-mop.jsonjson
{
  "id": "d4e5f6a7-890b-cdef-0123-456789012def",
  "org_id": "0b9e1f22-7a3c-4d55-8e16-2f4a6b8c0d1e",
  "owner_id": "a1234567-89ab-cdef-0123-456789abcdef",
  "name": "BGP Peer Change - Core Router DC1",
  "description": "Add new eBGP peer to ISP2 on core-rtr-01.dc1",
  "author": "jsmith",
  "revision": 2,
  "status": "approved",
  "risk_level": "high",
  "change_ticket": "CHG-3192",
  "tags": ["bgp", "core", "dc1"],
  "platform_hints": ["cisco-ios"],
  "estimated_duration_minutes": 30,
  "mop_lineage_id": "8f1c0a2b-3d4e-5f60-7182-93a4b5c6d7e8",
  "parent_id": "c3b2a190-6655-4433-2211-fedcba987654",
  "reviewed_by": "a1234567-89ab-cdef-0123-456789abcdef",
  "reviewed_at": "2026-03-10T14:30:00Z",
  "review_comment": "Verified BGP config and rollback. Approved for maintenance window.",
  "created_at": "2026-03-09T10:00:00Z",
  "updated_at": "2026-03-10T14:30:00Z"
}

Review decision payload

The body sent to POST /api/mops/{mop_id}/review. approved is a boolean; comment is optional but strongly recommended:

review-decision.jsonjson
// Approve
{
  "approved": true,
  "comment": "Reviewed all steps. Rollback plan looks solid. Approved."
}

// Reject
{
  "approved": false,
  "comment": "Missing post-check for BGP neighbor state. Add 'show ip bgp summary' and resubmit."
}

Checking approval status

Read the current decision by fetching the MOP and inspecting its status and review fields:

GET /api/mops/{mop_id}

# Response (relevant fields)
{
  "status": "approved",
  "reviewed_by": "a1234567-89ab-cdef-0123-456789abcdef",
  "reviewed_at": "2026-03-10T14:30:00Z",
  "review_comment": "Approved for maintenance window."
}
Change tickets

The optional change_ticket field links a MOP to your change-management system (ServiceNow, Jira, etc.), creating a cross-reference between the NetStacks MOP and the external change record for audit purposes.

Questions & Answers

Q: Who can approve a MOP?
A: A reviewer with the appropriate Controller permission. Approval authority is governed by your roles and permissions — grant the review capability only to users who should authorize changes.
Q: How many approvals are required?
A: One. The review is a single approve-or-reject decision; a single approval moves the MOP to approved. There are no multi-approver thresholds or "2 of 3" rules in the product.
Q: Can an approval be withdrawn?
A: There is no withdraw-approval action. If circumstances change after approval, archive the MOP or supersede it with a new revision that you submit for fresh review.
Q: What happens if a MOP is rejected?
A: The decision and the reviewer's comment are recorded on the MOP. To proceed, the author creates a new revision in the same lineage (POST /api/mops with the existing mop_lineage_id) that addresses the feedback, then resubmits it for review. The rejected revision and its comment are preserved.
Q: Can the author approve their own MOP?
A: The review endpoint does not enforce a separation between author and reviewer; it checks that the caller has review permission and that the MOP is pending_review. If you require independent review, enforce it through your role assignments and change process.
Q: Are approvals required for all MOPs?
A: The product does not auto-require approval based on risk level. A MOP only enters review when someone submits it (POST /api/mops/{id}/submit). Use your own operating policy to decide which procedures must go through review before execution.
Q: Where is the approval history kept?
A: On each MOP record as reviewed_by, reviewed_at, and review_comment. Because revisions are versioned within a lineage, you can trace a procedure's decisions across its revisions. The Controller audit log records the actions as well.

Troubleshooting

A reviewer cannot approve or reject

The reviewer must have the Controller permission to review MOPs, and the MOP must be in pending_review. A MOP that is still a draft has not been submitted yet — submit it with POST /api/mops/{id}/submit first. Check role assignments under Roles & Permissions.

Cannot edit a MOP

Editing (PUT) is allowed only while a MOP is a draft. A pending_review, approved, or rejected MOP is read-only — create a new revision instead of editing it. Deletion (DELETE) is not restricted by status, so prefer revisions over deletion when you need to preserve history.

Need to change an approved MOP

Approved MOPs are immutable. Push a new revision to the same lineage (reuse mop_lineage_id), then submit the new draft for review. The previous approved revision and its review record are kept.

Stopping a MOP that is already running

Approval governs the plan, not a live run. To stop an in-progress execution, use the abort/cancel control from the Task Monitoring dashboard.

Tip

Use the Audit Log to track review activity. Submit, approve, and reject actions are recorded with the user and timestamp; the decision comment lives on the MOP record.

The approval workflow connects to these NetStacks features: