Material requisition workflow fails on custom validation script for project-linked requests

ERP NetSuite
, , , , , , , ,
1

We’ve implemented a custom SuiteScript validation in our material requisition workflow (NetSuite 2024.1) that’s supposed to check project type compatibility before allowing requisitions to proceed. The validation works fine for standard projects, but fails completely when the requisition is linked to Time & Materials project types.

Here’s the validation logic causing issues:

var projectType = record.getValue('custbody_project_type');
if (projectType === 'T&M') {
    return {success: false, message: 'Validation failed'};
}

The workflow error logging isn’t capturing useful details - just generic ‘Script execution failed’ messages. Material requisitions for T&M projects are stuck in submitted status and can’t be processed. We need to understand why the custom validation script fails specifically for T&M project types and how to properly log the actual error details for troubleshooting. This is blocking our entire procurement workflow for about 40% of our active projects.

2

For workflow error logging, you need to implement custom logging in your validation script because NetSuite’s default workflow logs don’t capture script-level details. Create a custom record type for validation errors and write to it from your script. Include fields for: record ID, project type value, timestamp, and full error stack trace. This gives you much better visibility than the standard workflow execution log. Also make sure your script’s error handling returns properly formatted validation objects - NetSuite expects specific structure: {success: boolean, message: string}. If your script returns anything else or throws an exception, you get those generic error messages.

3

The null value explains the validation failure. Your script needs to handle the case where project type isn’t available yet during workflow execution. Consider moving the validation to a later workflow state or implementing a deferred validation approach.

4

The problem is definitely in your custom validation script’s error handling. When SuiteScript validation functions fail without proper try-catch blocks, NetSuite logs them as generic script execution failures. You need to wrap your validation logic in proper error handling and use log.error or log.debug to capture the actual failure point. Also, your validation is checking a custom body field that might not be populated at the time the workflow validation runs. T&M projects might have different field population timing than fixed-price projects. Add null checks before comparing values.

5

Your validation script is probably throwing an unhandled exception when it encounters T&M project types. The generic error message suggests the script is crashing rather than returning a proper validation result. Check if the custbody_project_type field value format matches what you’re comparing against - might be ‘Time and Materials’ instead of ‘T&M’.

6

Thanks for the debugging tips. I added try-catch blocks and found that the project type field is returning null for T&M projects when the validation runs. The field isn’t populated yet at that workflow stage.

7

Your validation failure is caused by three interconnected issues with custom SuiteScript validation, project type handling, and error logging. Here’s the comprehensive solution:

CUSTOM SUITESCRIPT VALIDATION FIX: Your validation script lacks proper error handling and field availability checks. Replace your current validation with this robust implementation:

try {
    var projectType = record.getValue('custbody_project_type');
    var projectRecord = record.getValue('job');

    if (!projectRecord) return {success: true};
    if (!projectType) projectType = getProjectType(projectRecord);
} catch(e) {
    log.error('Validation Error', e.toString());
    return {success: false, message: 'System error'};
}

The key is checking field availability before validation. Your original script assumes custbody_project_type is always populated, but T&M projects may have this field set through different workflows or timing. Implement a fallback function that loads the project record directly to retrieve the type if the custom field is null.

PROJECT TYPE HANDLING SOLUTION: T&M projects require special handling because their project type values may be stored differently than fixed-price projects. The issue is that NetSuite’s project type field can have different internal IDs versus display values. Your comparison ‘T&M’ is checking against the display text, but the field might contain the internal ID ‘2’ for Time & Materials projects. Modify your validation to check both:

Load the project record within your validation script using record.load with the job field value. Then access the native project type field (not your custom field) using projectRec.getValue({fieldId: ‘projecttype’}). This returns the internal ID. Create a mapping object: var projectTypes = {‘1’: ‘Fixed’, ‘2’: ‘T&M’, ‘3’: ‘Time Only’}. Use this mapping to properly identify T&M projects regardless of how the custom field is populated. This approach handles cases where the custom field isn’t yet populated during workflow execution.

WORKFLOW ERROR LOGGING IMPLEMENTATION: NetSuite’s default workflow logs don’t capture script-level errors effectively. Implement comprehensive custom logging:

Create a custom record type ‘Validation Error Log’ with fields: Record Type, Record ID, Project Type Value, Error Message, Stack Trace, Timestamp. In your validation script, wrap all logic in try-catch blocks and log to this custom record on any failure. Use log.audit for successful validations and log.error for failures - these appear in Script Execution Log with full context. Add this at the start of your validation function: log.audit(‘Validation Start’, 'Record: ’ + record.id + ', Project: ’ + record.getValue(‘job’)).

For the workflow itself, add a ‘Send Email’ action that triggers on validation failure, including the error details in the email body. This provides immediate visibility when validations fail. Configure your workflow to write validation results to a custom field on the requisition record (custbody_validation_status) so users can see why their requisition is stuck.

ROOT CAUSE AND PREVENTION: The fundamental problem is timing - your validation runs before project-related fields are fully populated. Move your validation to a later workflow state (after project assignment is confirmed) or implement a conditional validation that only runs if the project type field is populated. Add a workflow condition: IF custbody_project_type IS NOT EMPTY, THEN run validation script. This prevents validation failures on incomplete records while still enforcing rules when data is available.

8

I suspect the issue is that T&M projects have additional required fields that aren’t being validated before your custom script runs. When those fields are missing, your script can’t properly evaluate the project type. Check your material requisition form for T&M projects - are there conditional fields that only appear for certain project types? If your validation script tries to access fields that don’t exist in the T&M context, it’ll fail. You need to add conditional field checks in your validation logic.