Approvers approving their own request

I have a workflow that references department custom attributes for approvers. For each department, there are custom attributes 'Approver 1' and 'Approver 2' that are both people. I use these custom attributes in the Workflow Approval Step for a particular type of request. 

So my question is, if John Doe is the approver, and he also happens to be the Requestor in one case, will he need to approve his own request? Ideally he should not have to approve his own request. In my testing, it seems that the system still wants his approval. How can I make it so that approvers don't need to approve their own request?

Thanks!

Tags workflow tickets approvals
Asked by Mariah Rible on Mon 1/23/23 12:32 PM Last edited Mon 1/23/23 3:49 PM
Sign In to leave feedback or contribute an answer

Answer (1)

Mark Sayers Mon 1/23/23 1:08 PM

Hello Mariah,

Ideally you would configure your approval step such that it is assigned based on Role rather than being directly assigned to an individual, then for a fallback approver value, you could make it fall back to someone who would be considered responsible for anyone likely to use that particular type of service/request, so it's always being approved by someone who is higher in the org. chart than the actual Requestor.

Sincerely,
Mark Sayers
Sr Support Consultant, CS

No feedback
So there is no way to prevent approvers from approving their own request?

Our organization is laid out such that departments have their own people who approve requests from their employees, such as purchasing IT equipment. Each department has their own individual budget, so it would not make sense to have one person be a fallback approver for every department. Thus, the decision to create custom attribute(s) for each acct/dept that contains approvers made the most sense.
- Mariah Rible Mon 1/23/23 2:51 PM
Not if you're allowing values to be entered in a custom attribute where you're relying on the Requestor to fill in that custom person attribute, and the workflow is then assigning steps based on that field's value.

Perhaps the field should *not* be one the Requestor can enter and instead a tech must fill it out prior to the workflow being allowed to move on to that approval step, so you know it is being set appropriately.
- Mark Sayers Mon 1/23/23 2:55 PM
It's not a ticket custom attribute that the Requestor fills out, it's a department custom attribute that I, as an admin, fill out. - Mariah Rible Mon 1/23/23 2:57 PM
If you mean you're literally filling out a custom person attribute on an Acct/Dept (in TDAdmin > Organization Settings > Accts/Depts), there's no way for any of those attributes to be used specifically for assignments of approval type steps. You would have to use Condition steps to check for that field's value for the acct/dept of the ticket and have an approval step (potentially for each possible Acct/Dept) that makes the right assignment. - Mark Sayers Mon 1/23/23 3:03 PM
Maybe I’m misunderstanding. I added attachments that contain an example of a department with custom person attributes, and a picture of an Approval type workflow step where I can add those custom attributes as the approver role.

If I, as the Mobile Device Request Approver 1 for my department, IT Applications, submit a Mobile Device Request (the service for which this workflow is associated), should I need to approve myself? I’ve have tested it and it does make me approve my own request. Is this intended behavior? Can I avoid approving my own request? Is there a workaround or some other kind of workflow step that I can use to not require approval for this?

Sorry this has become such a back and forth, thank you for your help!
- Mariah Rible Mon 1/23/23 3:52 PM
You would almost have to additionally assign (as fallback approvers) each department manager and make the approval mode "Any" so they can take action on assignments from their own dept or choose to ignore the email if it's not for them. Supposedly if a role-based assignment equals to the same person that is the Requestor, it should use the fall-back assignment instead, but that may be only for the baked-in "manager" type role assignments. - Mark Sayers Mon 1/23/23 4:02 PM