Bom dia Matheus, obrigada a você pelo retorno e por considerar nossos comentários aqui. Perdão, só adicionarei uma outra opção que esqueci de comentar:
Para evitar alterar as ACLs neste caso, uma outra forma seria ter uma Business Rule que seja executada no "before", antes do registro de aprovação ser atualizado.
A Business Rule poderia ter uma condição para rodar sempre que o registro de aprovação for atualizado, especificamente durante a atualização do campo State da tabela sysapproval_approver.
Aqui é só um esboço, precisaria aprimorar as condições, mas em geral, a BR deveria executar em:
- Table: sysapproval_approver
- When: before | update
- Filter conditions:
- State changes | AND
- Source table is: sc_req_item | AND
- Approver >> is same as >> Approval.Approval for.Request.Requested for | AND
- Approver >> is (dynamic) >> Me
- Actions (na section de Actions da BR):
- Abort action (checked, flag marcada)
- Add message (checked, flag marcada, para permitir adicionar uma mensagem)
PS: para chegar ao Requested for ali no filter conditions, precisará realizar o dot-walking, para navegar a partir da Approval: exibir os Related Fields, navegar para a Approval for -> Task fields, depois Request (+) e por fim o Requested for.
Pois se você estiver utilizando a Requisição de maneira nativa, o campo Requested for estará na Request [sc_request], e não na Requested Item [sc_req_item], por isso a necessidade de navegar com o dot-walking para chegar ao Requested for da Request, a partir do Approval for.
Vale ressaltar que seria preciso testar muito bem, em diferentes locais em que a aprovação pode ocorrer de acordo com o que há disponível na instância (no Self-Service >> My Approvals da plataforma, no My Approvals do Service Portal, nas related lists de Approvals do Requested Item, no My Approvals do app Mobile... enfim, em todos em que forem aplicáveis).
Um local que eu acho que não funcionaria tão bem, seria a aprovação ou rejeição por E-mail (caso estejam utilizando algo como o Inbound Email Action para permitir ao usuário aprovar ou rejeitar através da resposta a uma notificação). Talvez a BR abortaria a transação (não permitiria aprovar ou rejeitar), mas o usuário que tentou aprovar ou rejeitar não ficaria sabendo (ele não veria a mensagem indicando que ele não pode aprovar). Neste caso, talvez precisaria tratar também no Inbound Email Action, para retornar a ele que a aprovação não pôde ser realizada por tal motivo.
Mas ainda cabe o que comentei no outro cenário (das ACLs), que de qualquer forma isso não impediria do usuário ver a aprovação e receber notificações sobre ela, o que poderia ser uma experiência um pouco ruim para ele (ele receberia algo para aprovar, mas ao tentar aprovar ou rejeitar apenas, que receberia uma mensagem o impedindo).
O melhor seria mesmo como o Willians sugeriu, de não impedir, mas tratar de uma forma a auditar as exceções. Ou como o Luiz sugeriu, de sempre buscar a aprovação do Gerente (se for viável, pois neste caso entendo que vocês estão usando a aprovação por Grupo).
Aqui alguns screenshots só para ilustrar o exemplo da Business Rule (vale ressaltar que não a testei):
----
----
----
