Stop, Continue, or Ignore

Expanded Definition

Stop, Continue, or Ignore is a failure-handling setting for custom workflow steps, not a general description of task status. It defines what the orchestrator should do when a step returns an error: stop the workflow immediately, let the workflow finish but report failure, or keep going and report success despite the error.

That boundary matters because the same control can be used for resilience, triage, or masking. Stop is the safest default when the step is security-sensitive or its output gates later actions. Continue preserves downstream execution while still surfacing an error condition. Ignore suppresses the failure signal, so it should only be used when the step is truly non-essential or when another control will independently detect the problem.

In practice, the term sits at the intersection of workflow orchestration and control assurance. It is not about the content of the step itself, but about how failure is propagated through the run.

Examples and Use Cases

These outcomes appear in automation platforms, integration pipelines, and approval workflows where a custom action may fail for reasons that do not always justify a full stop.

• A ticketing workflow stops when a custom validation step cannot verify required fields before creating a privileged access request.
• A deployment pipeline continues after a non-critical enrichment step fails, but the run is marked failed so the team can investigate.
• An ingestion workflow ignores a formatting-only custom step because the original record remains usable and a later quality control job will re-check it.
• A security workflow uses stop for identity enrichment or policy checks, because later actions should not proceed on incomplete or untrusted input.

The main trade-off is between operational continuity and confidence in the result. Continue and Ignore both reduce friction, but they increase the chance that an error becomes invisible to the people relying on the workflow output.

Security Implications

Misusing these outcomes can turn a small step failure into a control failure. If a security-relevant custom step is set to Ignore, the workflow may produce a successful run even though a policy check, validation step, or enrichment query did not complete. That creates false assurance, weakens auditability, and can allow downstream actions to proceed without the expected guardrail.

Continue is less dangerous than Ignore because it still preserves a failed end state, but it can still create exposure if operators treat the run as effectively successful and do not review the failure reason. Stop is usually the correct choice when the step protects authorization, data integrity, or compliance logic.

A common practitioner signal is a workflow that appears healthy at the job level while a key custom step is repeatedly failing. In that pattern, the control problem is not the exception itself but the failure-handling policy that prevents the exception from becoming visible enough to act on.

Domain and Governance Relevance

In identity and access workflows, these settings directly affect trust in the automation path. A step that validates identity attributes, checks privilege conditions, or confirms machine identity state should not be ignored simply to keep the run moving. If the step is part of a decision chain, Stop usually protects the integrity of the authorization outcome better than a permissive continuation rule.

The governance question is ownership: teams must decide which step failures are acceptable noise and which represent a broken control. That decision should be explicit, because the same workflow may contain both low-value enrichment steps and security-sensitive checks. For NHI-adjacent workflows, the setting can determine whether a missing token, certificate check, or service account lookup blocks the process or silently passes through.

OWASP Non-Human Identity Top 10 helps frame why failure handling matters when automation depends on machine identities and their credentials.

Related resources from NHI Mgmt Group

• What breaks when fraud controls stop at onboarding and ignore payout time?
• What breaks when fraud controls stop at checkout and ignore returns or refund abuse?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• How should teams stop LLMjacking when NHI secrets leak?