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 restrito do solicitante tem tipos de origem dedicados para identificar Workflow Studio origens de chamada.

Fluxo

O sistema usa o tipo de origem de fluxo para rastrear as operações executadas por ServiceNow Ações principais. Os registros de Privilégios de acesso restrito do solicitante 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 execute a ação Pesquisar registros em uma tabela entre escopos. Quando a restrição do chamador 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, todas as outras operações de leitura realizadas pelas ações principais também podem ser executadas. Por exemplo, seu 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 para a 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 de escopo cruzado específico. Os registros de Privilégios de acesso restrito do solicitante 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 do chamador 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 a partir de qualquer contexto. Por exemplo, você pode adicionar a ação personalizada a vários fluxos ou chamar a ação personalizada de um script. Desde que a ação personalizada execute a operação no recurso entre escopos 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.

Upgrade de privilégios de acesso restrito do solicitante para fluxos e ações

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

Antes de Iniciar

Se você habilitar a administração da aplicação 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 da aplicação 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 as funções de administrador específicas da aplicação e o 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 reconheceu fluxos e ações como tipos de origem. Os clientes que desejassem gerar registros de Privilégios de acesso de solicitante restrito para fluxos e ações só podiam fazer isso indiretamente. Eles podem usar uma inclusão de script ou regra de negócios para chamar um fluxo ou ação. Quando a inclusão de script ou a regra de negócios é 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. Adicione 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 do solicitante para as tabelas às quais você deseja que fluxos e ações solicitem acesso.
3. Se você estiver substituindo permissões de acesso baseadas em script existentes, identifique os fluxos e as 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 os privilégios existentes de inclusão de script e acesso à regra de negócios.
4. Gere solicitações de privilégio de acesso para quaisquer 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 para as tabelas definidas para restrição do chamador.
5. Permita que fluxos e ações acessem seus recursos da aplicação .
   Identifique solicitações de privilégio de acesso com estes 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 seus recursos restritos da aplicação geram uma solicitação de privilégio de acesso.

O que Fazer Depois

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