Process Instance Node
A Process Instance Node in Salesforce is a record on the ProcessInstanceStep object (and its newer ProcessInstanceNode counterpart) that represents a specific step within an active or completed approval process.
Definition
A Process Instance Node in Salesforce is a record on the ProcessInstanceStep object (and its newer ProcessInstanceNode counterpart) that represents a specific step within an active or completed approval process. Each Approval Process is composed of one or more steps; when a record enters the process, the platform creates a ProcessInstance record to track the overall approval journey, and creates a ProcessInstanceNode record for each step the record passes through. The nodes carry the approver identity, the action taken (approved, rejected, recalled, removed), the timestamp, and any comments the approver added.
The objects exist because approvals in Salesforce can be complex: parallel approvers, dynamic approver chains, criteria-based step entry, recall-and-restart cycles. The Process Instance Node records are the immutable audit trail of what actually happened at each step, who acted on it, when, and what they said. Compliance teams and process designers rely on these records for audit, debugging, and process improvement.
How Process Instance Nodes capture the step-by-step approval audit trail
The Approval Process object model
Salesforce approvals span four related objects. ProcessDefinition holds the configured approval process (its name, the entry criteria, the step definitions, the final actions). ProcessInstance is one execution of an approval process for one specific record; created when a record enters the process, completed when the process finishes. ProcessInstanceStep is the older step-level record (each row represents one step in one instance). ProcessInstanceNode is the newer, richer step-level record introduced in Spring 2018 with extended fields for parallel approvers and conditional behavior. The newer object replaces the older one for new process activities; the older object still exists for backward compatibility. Reports and integrations that touch approvals usually query the ProcessInstanceNode (or both objects if they cover legacy data) for the per-step history.
What each Process Instance Node carries
Each ProcessInstanceNode record holds the fields you need to reconstruct what happened at a step. The Status field shows whether the step is Pending, Approved, Rejected, Removed, or Recalled. The ActorId or NodeApproverId field shows which user (or queue, or role) was assigned. The Comments field captures whatever the approver wrote when acting. The Last Actor field shows the last user to take an action. The Process Order field shows the position of this node in the chain. The CreatedDate and CompletedDate fields show the time the node was created and when it completed. Together these fields tell the full story: who acted, what they decided, when, and with what context. Querying ProcessInstanceNode is the standard way to build an approval audit report or escalation dashboard.
Parallel approvers and the multi-node step
Salesforce Approval Processes support parallel approvers (require all approvers to approve, or require any one approver to approve). When a step is parallel, the platform creates one ProcessInstanceNode per approver in that step. Each node tracks the individual approver decision independently. The overall step status is computed from the per-node statuses based on the rule type: unanimous requires all nodes to be Approved, first response uses the first node to act. The Process Instance Node records are the only place this per-approver history is captured. If your approval reporting needs to surface who acted versus who timed out, query ProcessInstanceNode directly rather than relying on the aggregate step status alone.
Recall, reassignment, and the audit trail
Approvals are rarely linear. Approvers reassign to colleagues; submitters recall to revise the request; admins remove pending approvals during process redesign. Each of these actions creates additional ProcessInstanceNode records or updates existing ones. The audit trail preserves every action: a reassignment shows the original approver as Removed and a new node Created for the reassignee; a recall shows the entire process as Recalled with nodes preserved for the steps that completed before the recall. This append-only behavior makes the records useful for compliance audit but also makes the data volume on long-running, frequently-recalled processes substantial. Process designers should think about whether the audit detail justifies the storage cost on every approval; for low-risk processes, simpler workflows might fit better.
Reporting on Process Instance Nodes
Standard reports on the ProcessInstanceNode object cover the questions every approval implementation gets asked. How many approvals are pending right now and who is sitting on them? Which approvers are slowest to act? What is the rejection rate per process? Which processes most frequently get recalled? The platform ships a few standard report types that join ProcessInstanceNode with the parent ProcessInstance and the record being approved (the related record, joined through the TargetObject lookup on ProcessInstance). For bespoke reporting, custom report types let analysts join ProcessInstanceNode with custom objects and dimensions. Build the reports once and add them to a governance dashboard so process owners see the metrics regularly rather than ad-hoc when escalations arise.
Migration to Flow approvals and the Process Builder retirement
Salesforce announced the retirement of the older Process Builder and the Approval Process objects in favor of Flow-based approvals. Flow Orchestration (introduced as Salesforce Orchestrator in Winter 23 and renamed) provides the modern approval mechanism with similar step-level audit through Orchestration Run records (the Flow equivalent of ProcessInstance and ProcessInstanceNode). Salesforce has not set a hard retirement date for the older Approval Process feature, but new investment goes into Flow Orchestration. For new approval requirements, evaluate Flow Orchestration first. For existing Approval Processes still in production, they continue to fire and create ProcessInstanceNode records as before. Plan migration on a per-process basis when the time and budget allow.
Querying, reporting, and governing Process Instance Nodes
Working with Process Instance Nodes is mostly a reporting and audit activity, not a configuration one. The platform creates and updates the records automatically as Approval Processes run. The four-piece routine for the admin who owns approval governance covers: query Process Instance Nodes for current state, build standard reports on the object, monitor for stuck nodes that need intervention, and plan migration of legacy Approval Processes to Flow Orchestration when ready. Each piece is independent and can be adopted at the pace the team chooses.
- Query Process Instance Nodes for current state
From Developer Console or Workbench, run a SOQL query against ProcessInstanceNode to see the current state of approvals. SELECT Id, Status, ProcessInstanceId, NodeApproverId, CompletedDate FROM ProcessInstanceNode WHERE Status = Pending shows everything currently waiting. Filter by ProcessInstance.TargetObjectId to drill into a specific record. Filter by NodeApproverId to see what an individual approver is sitting on. Use this query pattern as the basis for any custom report, dashboard, or escalation logic. Document the canonical query patterns in your approval governance runbook so other admins do not invent slightly different versions.
- Build standard reports on the ProcessInstanceNode object
Create a Custom Report Type that joins ProcessInstanceNode, ProcessInstance, and the related record object (Opportunity, Case, custom object) through the TargetObjectId. Build the core reports: Pending Approvals by Approver (who is sitting on what), Average Time to Approve by Process (which processes are slow), Rejection Rate by Process (which processes get rejected most often), Recalled Approvals by Submitter (who is recalling and why). Add the reports to an Approval Governance dashboard. Schedule the dashboard to email approval owners weekly so process problems surface without manual digging.
- Monitor for stuck nodes and intervene
Build a dashboard alert (or Flow trigger) that flags any ProcessInstanceNode in Pending status for more than the configured SLA (typically 3 to 5 business days). For each stuck node, the alert should identify the approver, the request, and the elapsed time. Route the alert to the process owner or to a designated triage queue. The process owner can reassign the node to a backup approver, escalate to the manager, or recall the request for revision. Without active monitoring, stuck approvals quietly age and submit users learn to avoid the process entirely. Treat stuck-node intervention as part of approval governance, not as an emergency response.
- Plan migration to Flow Orchestration when ready
For each Approval Process in production, evaluate whether migration to Flow Orchestration adds value. Flow Orchestration provides richer step types (subflows, screen interactions, decision branches), better visual design, and Salesforce ongoing investment. Migration is a manual rebuild (no automated tool exists), so prioritize processes that gain the most from the new features. Document each rebuild in the org automation registry. Run both the old and new approval processes in parallel during a transition window so production work is not disrupted. Decommission the old Approval Process once the new Orchestration has been stable for a quarter.
- ProcessInstanceNode is read-only. The platform writes the records as approvals run; you cannot edit them directly. To change behavior, change the underlying ProcessDefinition (or migrate to Flow Orchestration).
- Recall and reassignment produce additional ProcessInstanceNode records. The audit trail is append-only, which is good for compliance but expands storage usage on processes with high recall volume.
- Parallel approval steps create one node per approver. Standard reports that count one row per step undercount parallel processes; build reports against the node-level table to capture per-approver detail.
- The older ProcessInstanceStep object still exists alongside the newer ProcessInstanceNode for backward compatibility. Cross-version reports may need to UNION both tables to cover all legacy data.
- Approval Process is in maintenance mode. Salesforce has not set a retirement date, but new investment goes into Flow Orchestration. Plan migration on a per-process basis when time allows.
Trust & references
Straight from the source - Salesforce's reference material on Process Instance Node.
- ProcessInstanceNode ObjectSalesforce Developer Docs
- Approval Process OverviewSalesforce Help
- Flow Orchestration OverviewSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Process Instance Node?
Q2. What does a node record?
Q3. How do nodes relate to process instances?
Discussion
Loading discussion…