NetSuite Saved Search: Filter POs by User Department

You need a saved search that shows every Purchase Order belonging to the same department as the person running it. The logic sounds simple, createdby.department = currentuser.department, but NetSuite doesn't expose a direct "current user department" field on the Purchase Order record. Here's how to build it using the native Department = Mine filter and a formula fallback when that doesn't cover your scenario.

The Native Filter That Works 90% of the Time

Open the saved search builder (Reports > Saved Searches > All Saved Searches > New > Transaction > Purchase Order). On the Criteria tab, add this filter:

This compares the Department field on the PO header against the department assigned to the employee record of the user executing the search. No formula required. Save and run, if your POs carry a department value (either entered manually or defaulted from the requestor), the results self-filter per user.

The Department = Mine filter evaluates at runtime for each user. It does not require the search to be public or shared; private searches respect the same logic.

When "Department = Mine" Falls Short

Two common gaps break the native filter:

1. The PO department is blank, the requestor didn't pick one, or the defaulting rule didn't fire.
2. You need the creator's department, not the PO's department, for audit trails where the PO department was changed after creation.

In both cases, switch to a Formula (Numeric) criterion.

Formula for Creator's Department vs. Current User

On the Criteria tab, add a new line:

• Field: Formula (Numeric)
• Operator: equal to
• Value: 1
• Formula:

CASE 
  WHEN {createdby.department} = {user.department} THEN 1 
  ELSE 0 
END

Critical detail: Use {user.department} (returns the internal ID), not a name-based variant. Mixing ID vs. name triggers a data-type error. The department record's internal ID is department, and {user.department} resolves to that numeric identifier at runtime.

Formula for PO Department vs. Current User (when header department is blank)

If the PO's own Department field is empty but the Created By employee has a department, use the same formula:

CASE 
  WHEN {createdby.department} = {user.department} THEN 1 
  ELSE 0 
END

The {createdby.department} join walks from the transaction to the employee record that created it. System notes confirm the Created By field is populated when a record is created, capturing the creator's identity, this is the same field the join references.

Verifying the Join Path

The {createdby} join is a system-maintained field on every transaction record pointing to the Employee who clicked Save. It is not the same as Created From (which links to a source transaction like a Purchase Request). If your search already includes Created From : Department = Mine, that filters on the source document's department, not the creator's.

To confirm which field you're actually filtering, add both columns to Results:

• Created By (shows employee name)
• Created By : Department (shows that employee's department)
• Department (shows the PO header department)

Run the search as two different users in different departments. The row-level values will reveal which field carries the data you need.

Edge Case: Department Hierarchy

If your organization uses department hierarchies (parent/child), {user.department} returns the specific department assigned to the employee, not the top-level parent. A user in IT > Infrastructure will not see POs tagged only to IT unless you explicitly roll up.

Workaround: create a Formula (Text) criterion that checks ancestry via CONNECT BY in a SuiteQL-backed saved search, or maintain a custom "Top-Level Department" field on the employee record and filter against that instead.

Quick Test Checklist

Before sharing the search:

1. Run as yourself, confirm your department's POs appear.
2. Have a colleague in a different department run it, confirm they see only theirs.
3. Check a PO with Department = blank, does it appear for the creator? (Only if you used the {createdby.department} formula.)
4. Verify the search is Public or shared to the relevant role so users can actually open it.

What to Check Next

If the formula returns zero rows for everyone, the {createdby} join may be empty on historical POs created via CSV import or SuiteScript without setting createdby. In that scenario, fall back to a Script Filter (SuiteScript 2.1 N/search module) that reads runtime.getCurrentUser() and compares against a custom custbody_creator_dept field you backfill on the PO record.

The native Department = Mine filter handles the standard use case. The formula handles the rest, no SuiteScript required unless your data has gaps the UI can't bridge.