Fix NetSuite Project Task Status Field ID Error
A workflow condition on project task status never fires on Completed. The status field holds an internal ID, not the label you see on screen.
Ethan James MarshalSenior SuiteScript Architect & Lead NetSuite Engineer
On this page
You set up a workflow to email your team when a project task hits Completed. The trigger works fine when you move a task from Not Started to In Progress. But the moment you edit the task and change it to Completed, the condition never evaluates to TRUE. Your workflow log shows the entry point fires, then the state transition check fails.
Here's the thing: the problem isn't your logic. It's the field ID the visual builder handed you.
The Field ID Bug in the Visual Builder
NetSuite's visual workflow builder has a known quirk with project tasks. When you build a state transition condition using the dropdown picker, it writes projecttask.status.id into the condition. The actual field ID on the record is status.id.
The visual builder prepends the record type (projecttask) to the field path. NetSuite then tries to evaluate projecttask.status.id as a field on the project task record, which doesn't exist. The condition silently fails, and your workflow never progresses past the state check.
The project task record itself uses the internal ID projecttask, which is correct for the record type reference. But the status field path should not include that prefix. For the full list of project task field IDs, check the SuiteScript Records Guide.
The Fix: Edit the Condition Field ID
Open your workflow in the visual builder and locate the state transition condition that checks for Completed. Click into the condition row and look at the Field column. If it shows projecttask.status.id, change it to status.id.
Save the workflow, then run a quick test:
- Open a project task currently set to Not Started
- Change it to In Progress and save
- Reopen the task, change it to Completed, and save
- Check the workflow execution log
The state transition should now evaluate to TRUE, and the email action fires.
Why After Submit Is the Right Choice
You mentioned this is your first workflow and you picked after record submit because it made sense. That's correct for this use case.
Before record submit runs after you click Save but before NetSuite writes the data to the database. The record hasn't been committed yet, so the status field still holds the old value. If you use before submit to check for Completed, it will always see the previous status, not the new one.
After record submit runs after NetSuite saves the record data to the database. The status field holds the updated value, so your condition evaluates against the actual saved state. That's what you want for sending a notification email. The SuiteFlow User Guide covers the full trigger execution model if you want the details.
One caveat: after submit triggers fire immediately after the save completes. In rare cases with heavy database load, the field value may not be fully committed when the workflow reads it. If you hit this, use a saved search as the workflow condition instead of the direct field comparison.
Building the Email Action
Once the condition evaluates correctly, the email action is straightforward. In your workflow, add a Send Email action on the state transition path. Configure these fields:
| Field | Setting |
|---|---|
| From | Select the employee or support email that should appear as the sender |
| Recipients | Add the project manager or team members who need the notification |
| Subject | Use a template like Project Task Completed: ${name} |
| Body | Include the task name, project name, and a link to the record |
Check the Include View Record Link box so recipients get a clickable link back to the task in NetSuite. The email will include a View Record link that takes the user directly to the project task record.
For the recipient list, you can select specific employees or use a field from the record, such as the task assignee. If you need to email someone outside NetSuite, create them as an employee record with their external email address. NetSuite requires recipient records to exist in the system to deliver workflow emails.
Testing the Complete Workflow
Deploy the workflow with the corrected field ID, then run through the full test sequence:
- Create a new project task
- Change the status from Not Started to In Progress, confirm the workflow enters correctly
- Edit the task again and change the status to Completed
- Verify the email arrives in the recipient's inbox
Check the workflow execution log after each step. You should see the state transition evaluate to TRUE on the second edit, and the email action should appear in the log with a success status.
What If the Condition Still Fails?
If you've corrected the field ID and the condition still evaluates to FALSE, switch the workflow condition to a saved search. Create a saved search on the project task record that checks the system notes for a status change to Completed. NetSuite supports this pattern: you can search system notes records to audit data changes, and the SuiteFlow User Guide documents using saved searches as workflow action conditions.
Use that saved search as the workflow entry condition instead of the direct field comparison. NetSuite runs the saved search immediately when the trigger executes and only proceeds if the record is returned by the search.
This approach reads the audit trail rather than the current field value, which sidesteps any timing issues with the after submit execution context. It's slightly more setup, but it's the reliable workaround when the direct field check won't cooperate.
The field ID fix should resolve your immediate problem. If you're building more complex project task workflows down the road, keep this quirk in mind: always verify the field path the visual builder generates. The SuiteScript Records Guide lists the correct internal IDs for project task fields, which saves you from hunting through generated code.
