1. Enable the Glide Transaction Log / Node Log
Set glide.processor.debug.type to all (or use session debug) and reproduce the error. The node log will show the exact table, field, and value that failed validation at the GlideRecord level — this is often the fastest path to the answer since the UI error message strips that detail.
2. Check Field-Level Dictionary Attributes and Validators
The error typically comes from a field whose value doesn't pass dictionary validation — a choice field receiving an unlisted value, a reference field getting an invalid sys_id, or a field with a max_length or regex validator. Compare the dictionary entries on pm_project (and any extended tables) between the customer instance and your PDI. Look specifically for dictionary overrides, since those won't show up as "customizations" to the workspace page itself but will affect record saves.
3. Use the Network Tab (Browser DevTools)
When you click submit, watch the XHR/Fetch calls in the Network tab. The POST or PATCH response body from the REST/GlideAjax call will often include more detail than what the UI toast message shows — sometimes including the offending field name and the value it rejected.
4. Inspect Business Rules with gs.setRedirect or Abort Actions
Run sn_debug.GlideRecordDebug or temporarily enable the "Show business rule details" session debug (glide.ui.show_business_rule_details = true). Even though you've debugged scripts, the culprit could be an async or before-insert business rule running in a different scope — especially if a plugin or store app added one that doesn't exist in PDI.
5. Compare Data Policies and UI Policies (Server-Side)
Data policies with "Apply to import sets / web services" enabled can trigger this error on workspace saves (which go through REST), even though they wouldn't fire in the classic form. Check sys_data_policy2 entries on pm_project and compare against PDI.
6. Audit the ACL Evaluation
Enable ACL debugging (glide.security.debug = true at session level). A write ACL that evaluates to false on a specific field can produce this message — the record still saves but the field that failed ACL gets rejected, causing the toast error while the rest of the insert succeeds.
7. Compare Plugin and Patch Levels
Since it works in PDI but not in the customer instance, check if the customer instance has a different patch level for the PPM plugins (com.snc.project, com.snc.project.workspace). A known defect in certain patch versions can cause this. Search the ServiceNow Known Error portal (HI) for "Invalid value on update" + "pm_project" — there are a few documented KBs/PRBs around this.
8. Clone-and-Strip Approach
If all else fails, clone the customer instance to a sub-prod, then systematically deactivate business rules, data policies, and dictionary overrides on pm_project until the error disappears. This brute-force method reliably identifies the culprit when the debugging tools above don't surface it.
My best guess based on the pattern you're describing (error fires but record still creates, works in PDI, no visible customizations): it's likely either a data policy enforcing a field value via REST that the workspace form doesn't populate, or a dictionary override on a choice/reference field where the customer instance has a stale or mismatched choice list compared to PDI. The Network tab response body should confirm which field is the offender within a couple of minutes.
