Service Order Lockout — Change Document v1.1.1.0
Date: 2026-03-20 Previous version: 1.1.0.1 Extension ID: a88ec3e1-11b8-4c5b-9dfd-e82c1741c408
Background
The v1.1.0.0 release introduced the BW-CS-SERVICE permission set as a gate for Service Order access and required SUPER to release another user's lock. Production deployment was blocked because:
- BW-CS-SERVICE is new — no Production users have it. Deploying without pre-assigning it would immediately block all CS users from opening Service Orders.
- SUPER is too broad for lock release — only IT admins (Phil, Rob, Hector, Nathan, Jen) have SUPER. CS supervisors (Allyson, Javier, Diana, Jamie, etc.) cannot release stuck locks without escalating to IT.
An investigation of the Production sandbox (200 enabled users) revealed two existing permission sets that map directly to the needed roles:
| Existing Permission Set | Users | Role |
|---|---|---|
BW-ASSIGNSVCORD | ~33 | All users who work with Service Orders (managers + temps + service accounts) |
BW-CS-MANAGERS | ~21 | CS supervisors who manage the team |
These permission sets are already assigned and maintained by the CS admin workflow. Using them eliminates the deployment blocker and the ongoing "remember to also assign BW-CS-SERVICE" tribal knowledge.
Summary of Changes
| # | Category | Description |
|---|---|---|
| 1 | Changed | Page gate now checks BW-ASSIGNSVCORD instead of BW-CS-SERVICE for Service Order access |
| 2 | Changed | Release Lock action now checks BW-CS-MANAGERS or SUPER instead of SUPER only |
| 3 | Added | Upgrade codeunit auto-assigns BW-CS-SERVICE to all users with BW-ASSIGNSVCORD for table-level permissions |
| 4 | Changed | UserHasSuperRole() refactored to generic UserHasRole(RoleID) for reuse |
| 5 | Changed | Error messages updated to name the specific permission set required |
Detailed Changes
1. Page Gate: BW-ASSIGNSVCORD (was BW-CS-SERVICE)
File: PageExt/ServiceOrder.PageExt.al — OnOpenPage trigger
The OnOpenPage permission check now looks for BW-ASSIGNSVCORD in the Access Control table instead of BW-CS-SERVICE. This permission set is already assigned to all 33 users who work with Service Orders in Production (CS managers, CS temps, and service accounts). No manual permission assignment is needed at deployment.
The fallback to SUPER is preserved — users with SUPER bypass the gate regardless of whether they have BW-ASSIGNSVCORD.
Why BW-ASSIGNSVCORD and not BW-CS-SERVICE: BW-CS-SERVICE was created in v1.1.0.0 and exists only on two test users in the sandbox. BW-ASSIGNSVCORD is the established permission set that CS admins already assign when onboarding new CS users. Gating on it means new users added after deployment automatically have access without a second permission assignment step.
Error message: 'You need the BW-ASSIGNSVCORD permission set to access Service Orders. Contact your system administrator to request access.'
2. Release Lock: BW-CS-MANAGERS or SUPER (was SUPER only)
File: PageExt/ServiceOrder.PageExt.al — ReleaseLock action, UserCanReleaseLock() procedure
The Release Lock action now permits users with either BW-CS-MANAGERS or SUPER to force-release another user's lock. Previously, only SUPER users could do this — meaning CS supervisors had to escalate to IT for a routine operational action.
The 21 users with BW-CS-MANAGERS are the CS supervisors (Allyson Sinquah, Javier Rosales, Diana Fridly, Jamie Risedorf, Cindy Salinas, Atsiry Sanchez, Sydnie Maya, Chris Collier, Josie Lesser, Jazmen Martinez, Jenna Holland, Shaneka Anderson, Sailyn P, Ben Copeland, Katie Hughes, Chad Manciagli, Bestway Product Safety, E Commerce, Ext 259, Ext 261, and one unnamed user). These are the people who manage the CS team day-to-day and are the right tier for lock management.
Three-tier access model:
| Tier | Permission Set | Can Open Service Orders | Can Release Others' Locks |
|---|---|---|---|
| CS Temps | BW-ASSIGNSVCORD + BW-CS-TEMPS | Yes | No |
| CS Managers | BW-ASSIGNSVCORD + BW-CS-MANAGERS | Yes | Yes |
| IT Admins | SUPER | Yes (bypass) | Yes |
Error message: 'You need the BW-CS-MANAGERS permission set or the SUPER role to release another user''s lock. Contact your system administrator to request access.'
3. Upgrade Codeunit: Auto-Assign BW-CS-SERVICE
File: Codeunit/ServiceOrderLockoutUpgrade.Codeunit.al — AutoAssignCSServicePermission() procedure
A new upgrade step runs when upgrading from any version prior to 1.1.1.0. It queries the Access Control table for all users with BW-ASSIGNSVCORD and inserts a corresponding BW-CS-SERVICE record for each one (if not already present). This provides the table-level permissions (Service Header Read/Modify, Setup Read) as a belt-and-suspenders measure, even though most users already have Service Header access through D365 BUS PREMIUM.
The procedure:
- Reads all Access Control records with
Role_ID = 'BW-ASSIGNSVCORD' - For each, checks if a
BW-CS-SERVICErecord already exists for that user and company - If not, inserts one with
Scope::Tenant - Version-gated to
< 1.1.1.0— runs once on upgrade, not on subsequent upgrades
4. UserHasRole() Refactor
File: PageExt/ServiceOrder.PageExt.al
UserHasSuperRole() was refactored to a generic UserHasRole(RoleID: Code[20]) procedure that accepts any role ID. This supports the new UserCanReleaseLock() procedure, which checks UserHasRole('SUPER') or UserHasRole('BW-CS-MANAGERS').
Object Inventory
| Object Type | ID | Name | Status |
|---|---|---|---|
| Page Extension | 52401 | ServiceOrder (extends Service Order) | Modified |
| Codeunit | 52402 | Service Order Lockout Upgrade | Modified |
| Permission Set | 52401 | BW-CS-SERVICE | Unchanged |
Deployment Notes
Pre-deployment
No manual permission assignment required. This is the key improvement over v1.1.0.0's deployment requirement. The upgrade codeunit handles BW-CS-SERVICE assignment automatically, and the page gate now checks BW-ASSIGNSVCORD (already assigned to all CS users).
Post-deployment verification
- Confirm a CS Manager (e.g., Allyson Sinquah) can open a Service Order and acquire a lock
- Confirm a CS Temp (e.g., Ext 248) can open a Service Order and acquire a lock
- Confirm a CS Manager can use the Release Lock action on a lock held by another user
- Confirm a CS Temp cannot use the Release Lock action (error message displayed)
- Confirm a SUPER user (e.g., Phil) can open Service Orders and use Release Lock without BW-ASSIGNSVCORD
- Verify the Service Order Lockout Setup page shows expected defaults (Enabled = true, Timeout = 4 hours)
Communication to CS team
Notify CS supervisors (users with BW-CS-MANAGERS) that they now have the ability to release stuck locks directly, without escalating to IT. The Release Lock action appears on the Service Order card when a lock is active.
Known Limitations
BW-CS-SERVICE still required for table-level permissions
The BW-CS-SERVICE permission set grants Read/Modify on Service Header and Read on the Setup table. While most CS users already have Service Header access through D365 BUS PREMIUM, the auto-assignment ensures coverage for users who may have a more restricted base permission set. If a user is added with BW-ASSIGNSVCORD but without D365 BUS PREMIUM or BW-CS-SERVICE, they will pass the page gate but may encounter table-level permission errors. The admin should assign BW-CS-SERVICE alongside BW-ASSIGNSVCORD for new users.
Upgrade codeunit runs once
The auto-assignment of BW-CS-SERVICE runs during the v1.1.0.1 → v1.1.1.0 upgrade only. Users added after the upgrade who receive BW-ASSIGNSVCORD will not automatically receive BW-CS-SERVICE. This should be documented in the CS user onboarding procedure.