---
sourceDocument: Australia Build workflows
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/build-workflows

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# ValidateSingleEnd

# ValidateSingleEnd {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of ValidateSingleEnd

The ValidateSingleEnd validator is designed to identify multiple End activities in a single workflow.
While having multiple End activities may sometimes be intentional, it can also lead to workflow issues if not managed properly.
Show full answer Show less  

## Key Features

* **Risk Assessment:** If execution paths to End activities are not mutually exclusive, the first End reached cancels other executing activities.
* **Severity Level:** Warning if multiple End activities are present.
* **Validation Results:**
  * **Valid:** The workflow contains 1 End activity.
  * **Invalid:** The workflow contains multiple End activities.
* **Suggested Action:** Remove unnecessary End activities to maintain clarity.

## Key Outcomes

Designing workflows with multiple End activities requires careful consideration. In large workflows, multiple Ends can enhance readability when paths are mutually exclusive. However, if paths are not mutually exclusive, it can lead to unintended cancellations of executing tasks. It's generally recommended to use a single End activity to ensure all intended tasks complete successfully before workflow termination.  
The ValidateSingleEnd validator finds and identifies multiple
End activities in a single workflow.
Multiple End activities in a workflow might be intentional and have no
affect on the workflow, or might be a mistake that the designer needs to correct.

## Validation summary

* Risk: If the execution paths to the End activities are not mutually exclusive, then the first End encountered completes the workflow and cancels all other executing activities.
* Severity Level: Warning
* Valid Result: Valid
* Valid Message: This workflow contains 1 End activity.
* Invalid Result: Invalid Activity
* Invalid Message: This workflow contains \<count of ends\> End activities.
* Suggested Action: Remove extraneous End activities that are not intended as part of the design.
* Publishable: Yes
* Runnable: Yes
* Related Information: None

## Troubleshooting

As soon as an End activity is encountered in the workflow, the
workflow completes even if there are other viable execution paths leading to a second
End activity that is still executing. Those executing activities
are canceled as part of the End activity's clean up actions.
Therefore, the results of designing workflows with multiple Ends must
be carefully considered.

In the case of large workflows, it is often more intuitive to read the workflow when there
are multiple End activities. In the following example, the paths to
the two Ends are mutually exclusive execution paths. If this was a
large workflow, with many activities between Branch and the second
End, the value of the multiple ends becomes apparent. Tracing a
No response from User is invalid to a single
End behind 33 other activities would be significantly more
difficult. There is no risk in this workflow design because there is no reason for other
activities to execute if the End after the
Notification activity terminates the workflow.  
Figure 1. Mutually exclusive execution paths

The next example has multiple End activities in execution paths that
are not mutually exclusive. A Yes response from User is valid causes the Set Values activity to finish
immediately. By reaching its End activity first, this execution path
cancels the Approval for Apps and the DB Task
activities, which might not be the desired outcome. If the paths are all expected to
complete before End, the activities should come to a
Join (as in the previous example) that transitions to a single
End.  
Figure 2. Mutually inexclusive execution paths  
Note:  
To add the second End, right-click to copy the original End activity and paste it onto the canvas. In most cases, a single End is the best and most reliable way to ensure that all activities expected to execute prior to workflow completion, do so successfully.