Acesso de solicitante restrito a Workflow Studio fluxos

Rastreie fluxos e ações que exigem acesso a recursos entre escopos. Permita ou negue fluxos e ações que exigem acesso a recursos entre escopos.

A tabela Privilégios de acesso de solicitante restrito tem tipos de origem dedicados para identificar Workflow Studio origens de chamada.

Fluxo

O sistema usa o tipo de origem de fluxo para rastrear operações executadas por ServiceNow ações do Core. Os registros de Privilégios de acesso de solicitante restrito permitem que um fluxo execute uma operação específica em um recurso entre escopos específico. Aprovar um fluxo para executar uma operação permite que qualquer outra ação principal no mesmo fluxo execute a mesma operação no mesmo recurso entre escopos.

Por exemplo, suponha que você tenha um fluxo que executa a ação Pesquisar registros em uma tabela entre escopos. Quando a restrição de solicitante está habilitada para a tabela entre escopos, a ação Pesquisar registros gera uma solicitação para executar uma operação de leitura. Quando você permite que o fluxo execute operações de leitura na tabela entre escopos, quaisquer outras operações de leitura realizadas por ações principais também podem ser executadas. Por exemplo, o fluxo pode executar as ações Pesquisar registro e Pesquisar anexos na mesma tabela entre escopos. Suponha que você adicione a ação Pesquisar registros da mesma tabela entre escopos a outro fluxo ou subfluxo. Como esta operação de leitura vem de outro fluxo, a ação principal gera uma solicitação de privilégio de acesso separada para aprovação. Se você configurar a ação Pesquisar registros para acessar outra tabela entre escopos, isso também gerará uma solicitação de privilégio de acesso separada para aprovação.

Ação de fluxo

O sistema usa o tipo de origem de ação de fluxo para rastrear operações executadas por ações personalizadas para um recurso entre escopos específico. Os registros de Privilégios de acesso do solicitante restrito permitem que uma ação personalizada execute uma operação específica em um recurso entre escopos específico. Aprovar uma ação para executar uma operação permite que a ação personalizada execute a operação no recurso entre escopos em qualquer contexto.

Por exemplo, suponha que você crie uma ação personalizada que execute a etapa Pesquisar registros em uma tabela entre escopos. Quando a restrição de solicitante está habilitada para a tabela entre escopos, a etapa Pesquisar registros gera uma solicitação para executar uma operação de leitura. Ao permitir que a ação personalizada execute operações de leitura na tabela entre escopos, você pode executar a ação personalizada em qualquer contexto. Por exemplo, você pode adicionar a ação personalizada a vários fluxos ou chamar a ação personalizada de um script. Contanto que a ação personalizada execute a operação no recurso de escopo cruzado de destino permitido, o sistema permitirá que a ação personalizada seja executada. Se você configurar a ação personalizada para acessar outra tabela entre escopos, a ação personalizada gerará uma solicitação de privilégio de acesso separada para aprovação.

Fazer upgrade dos privilégios de acesso de chamador restrito para fluxos e ações

Permita que instâncias atualizadas de San Diego e versões anteriores gerem solicitações de privilégio de acesso de solicitante restrito para fluxos e ações.

Antes de Iniciar

Se você habilitar a administração de aplicações para a aplicação de destino, somente os administradores da aplicação de destino poderão definir o acesso a uma aplicação. Se a administração de aplicações não estiver habilitada, um usuário administrador poderá definir o acesso a uma aplicação.

Função necessária: administrador da aplicação ou administrador

Nota:

Para saber mais sobre funções de administrador específicas da aplicação e desenvolvimento delegado, consulte Regras de controle de acesso em apps de administração de aplicações e Desenvolvimento e implantação delegados.

Por Que e Quando Desempenhar Esta Tarefa

Em San Diego e versões anteriores, a tabela Privilégios de acesso de solicitante restrito não reconhecia fluxos e ações como tipos de origem. Os clientes que desejavam gerar registros de Privilégios de acesso de solicitante restrito para fluxos e ações só podiam fazê-lo indiretamente. Eles podem usar uma inclusão de script ou regra de negócio para chamar um fluxo ou ação. Quando a inclusão de script ou a regra de negócio é executada, ela gera uma solicitação de privilégio de acesso ao recurso entre escopos para aprovação.

Aviso:

Atualizar privilégios de acesso de chamador restrito para rastrear fluxos e ações pode causar interrupções de serviço em instâncias que rastreavam anteriormente o acesso entre escopos de inclusões de script ou regras de negócios. Após o upgrade, todos os fluxos e ações que tentam acessar recursos restritos serão impedidos de executar e, em vez disso, gerarão suas próprias solicitações de privilégio de acesso restrito de chamador para aprovação. Alguém deve aprovar as solicitações de privilégio de acesso antes que os fluxos e as ações entre escopos possam ser executados. Os clientes que já permitiram o rastreamento indireto de fluxos e ações usando chamadas de script podem querer ignorar esta tarefa e continuar chamando fluxos e ações de scripts. Os clientes que desejam substituir seus privilégios de acesso existentes pelos novos tipos de origem de Fluxo e Ação de fluxo podem programar uma indisponibilidade para gerar e aprovar as novas solicitações de privilégio de acesso.

Procedimento

1. Adicionar uma propriedade do sistema.
   Crie esta propriedade.

   Campo	Valor
   Nome	com.glide.hub.flow.restricted_caller_access.track_flows_as_source
   Tipo	verdadeiro|falso
   Valor	verdadeiro

2. Defina o acesso entre escopos a um recurso da aplicação.
   Habilite a Restrição de solicitante para as tabelas às quais você deseja que os fluxos e ações solicitem acesso.
3. Se você estiver substituindo as permissões de acesso baseadas em script existentes, identifique os fluxos e ações entre escopos existentes que precisam de permissões de acesso.
   Você deve gerar novamente todos os privilégios de acesso existentes para fluxos e ações entre escopos. Os privilégios de acesso ao fluxo e à ação substituem a inclusão de script existente e os privilégios de acesso à regra de negócio.
4. Gere solicitações de privilégio de acesso para fluxos e ações entre escopos existentes.
   Você pode executar fluxos e ações entre escopos usando ou testando a aplicação entre escopos.
   Fluxos e ações entre escopos geram solicitações de privilégio de acesso às tabelas definidas para restrição de solicitante.
5. Permita que fluxos e ações acessem os recursos da aplicação.
   Identifique as solicitações de privilégio de acesso com esses tipos de origem.

   • Fluxo
   • Ação de fluxo

   Defina o Status como Permitido para cada operação que você deseja que um fluxo ou ação execute em seu recurso de aplicação restrito.

Resultado

Fluxos e ações que tentam acessar os recursos restritos da aplicação geram uma solicitação de privilégio de acesso.

O que Fazer Depois

Revise e aprove as solicitações de privilégio de acesso do registro da sua aplicação.