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 do 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 as operações executadas por ServiceNow Ações principais. Os registros de privilégios de acesso do solicitante restrito permitem que um fluxo execute uma operação específica em um recurso específico entre escopos. A aprovação de 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 de escopo cruzado. Quando a restrição do chamador está habilitada para a tabela de escopo cruzado, 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 de escopo cruzado, 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 de escopo cruzado 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 da ação de fluxo para rastrear operações executadas por ações personalizadas para um recurso específico entre escopos. 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 específico entre escopos. A aprovação de uma ação para executar uma operação permite que a ação personalizada execute a operação no recurso de escopo cruzado em qualquer contexto.

Por exemplo, suponha que você crie uma ação personalizada que execute a etapa Pesquisar registros em uma tabela de escopo cruzado. Quando a restrição do chamador está habilitada para a tabela de escopo cruzado, 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 de escopo cruzado, 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 a partir de um script. Desde 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 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 restrito do chamador 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 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 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 do 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ócio era executada, geraria 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 existentes entre escopos 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 de acesso à regra de negócio e inclusão de script existentes.
4. Gere solicitações de privilégio de acesso para quaisquer fluxos e ações existentes entre escopos.
   Você pode executar fluxos e ações entre escopos usando ou testando a aplicação entre escopos.
   As ações e fluxos 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 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

Os 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 solicitações de privilégio de acesso do seu registro de aplicação.