New Project Workspace - Unexpected Behavior of some Business Rules

[iekosmadakis]

Has anyone noticed that the business rules don't behave as expected in the new Project Workspace?

For example all rules that contain the command "current.setAbortAction(true)" cause problems since script include "ProjectWorkspaceSaveApi" throws an error when saving the changes.

Is that why - by default - they are set to not run here by default?

Btw I followed this knowledge article to enable their firing: Businsss rule is not triggered in Project workspace - Support and Troubleshooting (servicenow.com)

[Marcos Gianoni]

The core difficulty being faced is a conflict between traditional server-side abort logic and the modern Workspace architecture:

Business Rules using current.setAbortAction(true) are failing and causing an error within the Out-of-the-Box (OOTB) script include ProjectWorkspaceSaveApi, which prevents the record from being saved in the New Project Workspace.

1. Understanding the Root Cause of the Difficulty

The problem stems from how the New Project Workspace handles data saving, which differs significantly from the classic UI16 form interface:

• UI16 (Classic Forms): Processing is synchronous. A before Business Rule executing setAbortAction(true) immediately halts the transaction and returns an error message to the user.

• New Workspaces: These use modern APIs (like the ProjectWorkspaceSaveApi) that orchestrate saving, often asynchronously or via a distinct transaction lifecycle. When a traditional Business Rule attempts to abort the action, the new Save API is likely not correctly programmed to handle the native transaction abort. Instead, the OOTB script include fails because it doesn't know how to gracefully manage this unexpected interruption, resulting in a script runtime error.

The fact that the user had to enable BR execution (as per a knowledge article) confirms that ServiceNow intended to separate this execution path to prevent such conflicts.

2. Immediate Solution and Mitigation (Best Practice)

Since the error originates in the OOTB code (ProjectWorkspaceSaveApi), this difficulty is classified as a Platform Bug.

The correct action, according to ServiceNow best practices, is:

1. Report the Bug: Immediately raise a High-Priority Support Ticket with ServiceNow. The platform engineering team must be notified of the bug in their OOTB code so they can develop and release an official fix in a patch or hotfix.

2. Reference Details: When opening the ticket, specify that the failure occurs within the OOTB script include ProjectWorkspaceSaveApi when attempting to process a Business Rule that executes current.setAbortAction(true).

3. Best Practice Recommendation for Abort Logic

While waiting for the official fix, if the Business Rule's validation logic is critical, consider these alternatives for preventing a save operation in the Workspace context:

Alternative	Where to Apply	Workspace Advantage
1. Data Policies	Form/Table	Use Data Policies to enforce required fields or read-only states, preventing the save without needing any code (best performance).
2. Client Scripts OnSubmit	Workspace Application (UX)	Perform validation on the client side. If validation fails, use return false; in the Client Script. Workspace clients are generally better equipped to handle client-side aborts cleanly.
3. Validation & Messaging	Business Rule before	If complex logic is required, maintain the BR but understand that while you can send an error message, the native abort function may continue to crash the Save API until the official ServiceNow patch is applied.

In summary, your difficulty is valid, points to an OOTB API bug, and the only permanent solution is an official patch from ServiceNow.