Granular Delegation: Table Choices and Flows

[ctsmith]

Trying to implement granular delegation and two areas I'm not quite getting.  Table choices.  Maybe people have said no, don't use the sysapprover table and the documentation says it needs to be a task table.  Ok, fine, I'll start with request item table.  Got that in.  But then we have to have conditions for what request items can be delegated and here I'm stuck.  The delegator should only delegate to the delegatee their approvals, correct?  How do you choose that in a condition on the sc_req_item table since it does not reference back to the approvals table?  Second, our approvals, much like just about everyone else, run on flows.  And the documentation states: "Note: Flows and workflows ignore delegation rules. If you use flows or workflows to manage task approvals or assignments, you must use the existing service delegation features instead."  Does that make this granular module mostly useless since flows control just about all our approvals whether through request or change?  Or am I misreading this?

Thanks!

[RobertR1]

Hi, I was just wondering the same - the Note"..." comment through me off when reading the official documentation.
As far as I know it should work for tasks and approvals created via Flow.

Did you end up implementing this and do you perhaps have any updates?
Cheers,
Robert

[ctsmith]

Here's the run down I got for support on my delegation questions:

ISSUE SUMMARY: Granular Delegation Help — clarification needed on two points:

1. How to scope a delegation rule on sc_req_item so only the delegator's approvals are delegated, given sc_req_item does not reference the approvals table.
2. Whether the documented caveat "Flows and workflows ignore delegation rules" makes Granular Delegation effectively unusable for flow-driven approvals.

STEPS TO REPRODUCE/OBSERVE BEHAVIOR: N/A

MOST PROBABLE CAUSE: Expected product behavior — clarification of design intent rather than a defect. The rule-conditions field on sc_req_item is for record-level filtering only; delegator-to-approval scoping is handled automatically by the platform via global.ApprovalDelegationUtil. Additionally, the flows/workflows caveat in the documentation applies to flow-generated task assignments, not to approvals created via the "Ask For Approval" flow action.

RESOLUTION:

For Q1: The condition on sc_req_item only filters which RITMs are eligible for delegation. The "only this delegator's approvals" scoping is handled by global.ApprovalDelegationUtil, which queries sysapproval_approver for approvals where the approver is the delegator. This setup is confirmed to work on sc_req_item and change_request per this community thread.

If approvals do not surface for the delegate in Employee Center, verify the Approvals To-do configuration includes:
"Sys ID is javascript:new global.ApprovalDelegationUtil().getMyAndDelegatedApprovals() OR Approver is javascript:new global.ApprovalDelegationUtil().getApprovers()".

Also note, per KB2539817, Granular Delegation does not retroactively apply to approvals that existed before the rule was created — only new ones.

For Q2: The doc caveat applies to task assignments generated by flows (e.g. a flow assigning an sc_task to a user — that won't auto-reassign to the delegate). It does not apply to approvals created via the "Ask For Approval" flow action.

Validated end-to-end on your sub-prod instance taniumbuild with the following setup:

• Delegation Rule on Incident: Incident Approval Delegation
• Granular Delegate: Manager A → User D (with the above rule attached)
• Flow with "Ask For Approval" action: Test Granular Delegation Flow
• Triggered via: INC0XXXXXX

Result: the delegate (User D) sees the flow-generated approval in Employee Center → My Tasks, clearly labeled "Delegated", with working Approve / Reject buttons. So Granular Delegation is fully usable for your flow-driven approval needs.