Assigning a service-delivery manager now honours the exact permission granted

When you give someone a permission, the interface should behave as it reads. “Assign a service- delivery manager to a lead” is one permission, and “assign a customer-success manager” is another — and until now the action that actually made the assignment checked the wrong one of the two.

Specifically, the “Assign SDM” action was gated on the CSM assignment permission rather than the SDM one. For workspaces using the standard role templates this went unnoticed, because the two permissions are granted together there. But a workspace that granted a single user only the SDM permission — a deliberate, narrow grant — would see the assignment offered and then be refused when they tried to use it.

The action now checks exactly the permission the assignment is meant to require. A grant of the SDM assignment permission, however narrow, does what it says: the associated assignment works, and the CSM assignment still sits behind the CSM permission.

What this means for you

Nothing changes for workspaces on the standard role templates. What changes is trust in the permission model itself: a fine-grained grant now behaves the way it is written, so an administrator can reason about what access a user actually holds without an assignment quietly failing underneath them.