HowTo: Removing Engineering Components Access Control from a ProjectWise Work Area with PowerShell

Be sure to check out my Scripting4Crypto initiative. It’s a fun way to get into using cryptocurrencies all while getting your PowerShell needs met.

If you manage ProjectWise environments long enough, you eventually run into inconsistent or legacy access control entries—especially with Engineering Components (EC) permissions on Work Areas. These ACLs can be inherited, copied forward from templates, or manually added over time, and they don’t always reflect how you want security managed today.

In this post, I’ll walk through a PowerShell approach to identify and remove Engineering Components access control entries from a selected ProjectWise Work Area using the ProjectWise SDK and a backend SQL query.

⚠️ Disclaimer:
This script directly removes access control entries. Always test in a non-production environment first and ensure you have proper backups and administrative privileges before running this in production.

The Problem

ProjectWise stores access control information in the backend database. Engineering Components permissions are stored with an object type value of:

• o_objtype = 5 (Engineering Components)

Over time, Work Areas can accumulate EC access entries that no longer align with your security model. Unfortunately, there isn’t always a clean way to bulk-remove these from the UI—so scripting becomes your friend.

The Solution

This PowerShell snippet does the following:

1. Prompts the user to select a ProjectWise Work Area

2. Queries the ProjectWise database (dms_acce) for Engineering Components ACLs tied to that Work Area

3. Loops through each access control record

4. Removes each ACL entry using the ProjectWise API

This gives you a targeted, repeatable way to clean up Engineering Components permissions.

PowerShell Script

$pwFolder = Show-PWFolderBrowserDialog -InitialFolderPath 'Projects' -DialogTitle "Select Work Area"
$FolderID = $pwFolder.ProjectID
$sqlQuery = "SELECT * FROM dms_acce 
                WHERE o_aclno IN (
                    SELECT o_aclno 
                    FROM dms_proj 
                    WHERE o_projectno = $FolderID
                ) AND o_objtype = 5"
if($sqlResults = Select-PWSQL -SQLSelectStatement $sqlQuery){
    Write-Host "$($sqlResults.Rows.Count) Engineering Components access records returned." -ForegroundColor Cyan
    foreach($row in $sqlResults.Rows){ # break
        $Message = "(MemberType: $($row.o_memtype); MemberID: $($row.o_memberno))"
        if([pwwrapper]::aaApi_RemoveAccessList(5, $FolderID, 0, 0, 0, $row.o_memtype, $row.o_memberno)){
            Write-Host "$($sqlResults.Rows.Count) Engineering Components access records returned $Message." -ForegroundColor Cyan
        } else {
            Write-Warning -Message "Failed to remove Engineering Components access record. $Message"
        }
    } # foreach($row in $sqlResults.Rows)...
} else {
    Write-Warning -Message "No Engineering Components access records returned."
}

How It Works

1. User Selects a Work Area

$pwFolder = Show-PWFolderBrowserDialog -InitialFolderPath 'Projects' $FolderID = $pwFolder.ProjectID

This uses the ProjectWise folder browser dialog to let the user pick a Work Area. The selected folder’s ProjectID is used as the key identifier for the query and API call.

2. Querying the Backend Database

SELECT * FROM dms_acce WHERE o_aclno IN ( SELECT o_aclno FROM dms_proj WHERE o_projectno = $FolderID ) AND o_objtype = 5

This query:

• Finds ACL numbers tied to the selected Work Area (dms_proj)

• Filters only Engineering Components access records (o_objtype = 5)

• Returns each access control entry that needs to be removed

3. Removing Access Control via the SDK

[pwwrapper]::aaApi_RemoveAccessList(5, $FolderID, 0, 0, 0, $row.o_memtype, $row.o_memberno)

This call removes the Engineering Components access record for each user or group tied to the Work Area.

You’ll notice that:

• The object type (5) corresponds to Engineering Components

• The member type and member ID come directly from the database row

• This ensures you remove exactly what exists in the backend

Safety Tips

Before using this in production:

• ✅ Test against a non-production datasource

• ✅ Add a -WhatIf or confirmation prompt if building this into a reusable tool

• ✅ Log all changes to a file for auditing

• ⚠️ Never run direct SQL modifications against ProjectWise — always use the SDK for write operations

Final Thoughts

This pattern—querying ProjectWise metadata via SQL and performing changes via the SDK—is incredibly powerful when you need to clean up or normalize permissions across your environment. Engineering Components ACLs are just one example, but the same concept applies to many other ProjectWise administration tasks.

If you routinely manage large sets of Work Areas, automating this kind of cleanup can save hours of manual effort and reduce security drift over time.

Experiment with it and have fun.

Hopefully, you find this useful. Please let me know if you have any questions or comments.  If you like this post, please click the Like button at the bottom of the page. And thank you for checking out my blog.