Delegate an operation, not a vague role

“Help desk” is a job label; a delegation must say exactly what that job can change.

Objects and operations

Active Directory permissions can delegate administration over selected objects. Organizational units provide a useful scope, but placing objects together does not automatically grant every administrative operation over them.

Password reset, account creation, and group-membership changes are distinct authorities. Inheritance and the types of child objects covered also matter. Review effective permissions, not only the name of a support group or a screenshot of a delegation wizard.

Supplied record: the evening college

The fictional college gives Niko a support role with these reviewed conditions:

Identity: Niko belongs to Learner-Helpdesk.
Grant: reset passwords on user objects beneath the Learners organizational unit.
Business rule: verify an approved support request before a reset.
Other authority: no account-creation or group-membership rights.
Staff organizational unit: outside this delegation.

Assume these are effective permissions for ordinary, unprotected learner accounts, with the stated inheritance and no other administrative grants. A permitted reset for a Learners user does not establish authority to create another user, alter a group, or reset a Staff password.

Write the boundaries as decisions

Your decision table should identify the target object and requested operation before judging permission. Approving an operation on one learner does not approve every request simply because the operator is technically able to perform it.

Record the responsible college owner, required support evidence, and the allowed and denied outcomes to preserve. Password-reset authority is consequential: keep the operator accountable and the reset attributable. If the role later needs another task, review that task’s scope explicitly instead of replacing the narrow grant with full control.