Throw Exception

Audience: Low-code Engineers

Skill Prerequisites: Actions, Conditions

Raises an error on purpose, which stops the current flow of actions. Use it with a condition to stop processing when data is invalid or a business rule isn't met.

The error can have two messages: an Admin Message with technical details for low-code engineers, and a Friendly Message for end users.

Typical Use Cases

• Stop a submission when a business rule fails, for example an order quantity above the available stock
• Fail a workflow or API call when a required value is missing, so the caller gets an error
• Trigger the On Error actions of an enclosing Execute Actions or Repeat
• Test error handling while building an application

Don't use it to

• Show a normal validation message on a form. Use Display Error Message or field validation instead.
• Stop without an error. Use Stop Execution instead.

Related Actions

Action Name	Description
Execute Actions	Catches the error with its On Error actions.
Stop Execution	Stops the remaining actions without raising an error.
Display Error Message	Shows an error message to the user.
Log Error	Writes a message to the log without stopping.

Input Parameter Reference

Parameter	Description	Supports Tokens	Default	Required
Admin Message	The technical message for low-code engineers and administrators, for example Order [OrderId] rejected: quantity [Quantity] exceeds stock [Stock]. It's also the value of the [ExceptionMessage] token in On Error actions.	Yes	empty string	No
Friendly Message	The message for end users, for example Sorry, we don't have enough stock for this order.	Yes	empty string	No

What users see

If the error isn't caught by an On Error list, the module's error handling decides what's displayed:

User	Message shown
Administrators and users in the Low-Code Engineer role	The Admin Message
Everyone else	The Friendly Message

If the error is caught by the On Error actions of Execute Actions or Repeat, nothing is shown automatically. The On Error actions decide what happens, and [ExceptionMessage] contains the Admin Message.

Considerations

• Fill in both messages. If Friendly Message is empty, end users may see an empty error. Keep technical details, such as IDs or SQL, out of Friendly Message.
• Add a condition. Without a condition, the action always fails. Put the rule in the action's Condition, for example [Status] == "Closed". See Common Parameters.
• In workflows and APIs, the error fails the run and is returned to the caller.

Examples

tip

To understand how to use the below examples, please see Running Examples.

1. Reject a request for a closed project

This action stops execution with an error when the Status token is Closed. Administrators see which project was affected. Other users see a plain explanation.

{
    "Title": "Throw Exception",
    "ActionType": "ThrowException",
    "Description": "Block requests for closed projects",
    "Condition": "[Status] == \"Closed\"",
    "Parameters": {
        "AdminMessage": "Request rejected: project [ProjectId] has status [Status].",
        "FriendlyMessage": "This project is closed and can't accept new requests."
    }
}

Revised 09/25/2026