Learn how to configure field-level editability rules in the Project Workspace grid using ProjectWorkspaceColumnCriteriaSNC script.

DISCLAIMER: This article describes a proposed solution to support this use case. The proposed solution requires configuration; as such, there is no liability for ServiceNow to provide support, apply changes, fix defects, or review impact during future upgrades.

 

What problem does this solve?

Project managers often need field-level control over which grid columns are editable — and under what conditions. For example:

• Closed tasks — certain fields should be disabled.
• Only the assignee’s manager should be able to change the assignment.
• Priority should be disabled once a task becomes inactive.

Traditional ACLs work on forms, but the Project Workspace grid uses a client-side DataGrid. Out-of-box, there is no built-in way to conditionally disable individual columns per row.

Starting with the Project Workspace 7.1.0 release, the ProjectWorkspaceColumnCriteriaSNC script include provides an override point to define column-level editability rules — effectively giving you field-level ACL behavior inside the grid.

 

Prerequisites

• ServiceNow Zurich or later.
• Project Workspace 7.1.0 (sn_pw) plugin activated.
• Admin or scoped-app developer access.

How it works

1. The platform ships a base script include: ProjectWorkspaceColumnCriteriaSNC.
2. You create (or update) the extension point: ProjectWorkspaceColumnCriteria — which overrides the getConfig(table) method.
3. The grid reads your config, fetches any required hidden fields, and disables editing client-side for cells that match your criteria.

Key concept: The criteria you define specifies when a cell should be disabled (not when it should be enabled).

 

Supported operators

Operator

|

Meaning

|
|

=

|

Equals

|
|

!=

|

Not equals

|
|

IN

|

Value in comma-separated list

|
|

ISEMPTY

|

Field is empty

|
|

ISNOTEMPTY

|

Field is not empty

|
|

> >= < <=

|

Numeric / date comparisons

|

Multiple conditions can be chained with ^ (AND).

 

Solution

 

Step 1- Create the Script Include

Navigate to System Definition > Script Includes and create:

Field

|

Value

|
|

Name

|

ProjectWorkspaceColumnCriteria

|
|

API Name

|

sn_pw.ProjectWorkspaceColumnCriteria

|
|

Application

|

Project Workspace

|
|

Accessible from

|

This application scope only

|

 

Step 2 - Override getConfig() with your rules

Below are practical examples. Select the examples relevant to your use case and add them to your getConfig() method.

 

Base template

    var ProjectWorkspaceColumnCriteria = Class.create();
    ProjectWorkspaceColumnCriteria.prototype=Object.extendsObject(ProjectWorkspaceColumnCriteriaSNC, {
    getConfig:function(table) {
        var config = {};
        if (table ==='pm\_project\_task') {
            // Add your rules here (see examples below)
         }
        return config;
    },
    type:'ProjectWorkspaceColumnCriteria'
});

 

Example 1- Disable a field when a task is closed

Scenario: Prevent users from changing the Start Date on closed tasks.

config['start\_date'] = {
    criteria:'state=3',
    requiredFields: ['state']
};

state=3 means “Closed”. The cell becomes disabled when the task’s state is 3.

 

Example 2 - Disable a field for multiple states

Scenario: Disable End Date when the task is Closed ( 3), Cancelled ( 4), or Pending (-5).

 

config['end\_date'] = {
    criteria:'stateIN3,4,-5',
    requiredFields: ['state']
};

The IN operator matches any value in the comma-separated list.

 

Example 3 — Disable a field when another field is empty

Scenario: Disable editing Short Description until someone is assigned.

config['short\_description'] = {
    criteria:'assigned\_toISEMPTY',
    requiredFields: ['assigned\_to']
};

ISEMPTY disables the cell when assigned_to has no value.

 

Example 4 - Disable a field based on a boolean

Scenario: Disable Priority on inactive tasks.

config['priority'] = {
    criteria:'active=false',
    requiredFields: ['active']
};

 

Example 5 - Dot-walk: disable based on assignee’s manager

Scenario: Only the assignee’s manager should be able to change the Assigned To field. For everyone else, it should be disabled.

var currentUserId = gs.getUserID();
config['assigned\_to'] = {
    criteria:'assigned\_to.manager!='+ currentUserId,
    requiredFields: ['assigned\_to.manager']
};

How it works: The criteria walk from assigned_to to manager and compares it to the logged-in user. If the current user is not the manager, the cell is disabled.

Important: Dot-walked fields must appear in requiredFields so the grid fetches them as hidden columns.

 

Example 6 - Dot-walk: disable based on assignee’s department

Scenario: Disable Work Notes unless the assignee belongs to the IT department (sys_id = abc123...).

config['work\_notes'] = {
    criteria:'assigned\_to.department!=abc123def456',
    requiredFields: ['assigned\_to.department']
};

Replace abc123def456 with the actual sys_id of the department record.

 

Combining multiple rules

You can define rules for as many columns as needed — just add more keys to config:

if (table ==='pm\_project\_task') {
    config['start\_date'] = {
        criteria:'state=3',
        requiredFields: ['state']
    };
    config['end\_date'] = {
        criteria:'stateIN3,4,-5',
        requiredFields: ['state']
    };
    config['priority'] = {
        criteria:'active=false',
        requiredFields: ['active']
    };
}

Each column gets its own independent criteria. The grid evaluates them per row.

 

Step 3 - Verify

1. Open a project in Project Workspace.
2. Navigate to the Planning tab (grid view).
3. Try to inline-edit a field on a row that matches your criteria — the cell should be disabled.
4. Confirm that rows not matching the criteria remain editable.

Quick reference

Use case

|

Criteria string

|

requiredFields

|
|

Disable when Closed

|

state=3

|

['state']

|
|

Disable when inactive

|

active=false

|

['active']

|
|

Disable for multiple states

|

stateIN3,4,-5

|

['state']

|
|

Disable if no assignee

|

assigned_toISEMPTY

|

['assigned_to']

|
|

Disable based on manager (dot-walk)

|

assigned_to.manager!=<userId>

|

['assigned_to.manager']

|
|

Disable based on department (dot-walk)

|

assigned_to.department!=<sysId>

|

['assigned_to.department']

|

 

Important notes

• Criteria = disable condition. Define when the cell should be disabled , not when it should be allowed.
• Dot-walked fields must be listed in requiredFields so the grid fetches them as hidden columns.
• Dynamic values (like current user) must be resolved server-side in getConfig() using gs.getUserID(), gs.getUser().getRecord(), etc.
• This does not replace server-side ACLs. It provides client-side grid enforcement as a complement to ACLs.