segunda-feira, 10 de julho de 2023

Migração de projetos para o Project for the web

 Olá pessoal –

Tenho percebido um número cada vez maior de empresas que tem optado pelo Project for the web como solução definitiva de gerenciamento de projetos, em detrimento ao Project Online. Em alguns casos, empresas que gerenciam seus projetos ativamente no Project Online têm feito planos para migrar seu portfolio para o Project for the web – um indicador de que, no médio/longo prazo, essa plataforma ganhará cada vez mais adeptos.

Recentemente apoiei um cliente em um processo de automação via Power Automate para realizar a migração do portfolio de projetos do Project Online para o Project for the web, e gostaria de documentar aqui minhas descobertas e lições aprendidas. O escopo geral do trabalho seria migrar os projetos em andamento do Project Online para o Project for the web (cerca de 350 projetos no total), englobando apenas as informações de nível de projeto, como nome, proprietário, patrocinador e demais atributos – cronogramas/tarefas não seriam migrados.

É importante ressaltar que os mesmos passos também podem ser aplicados por uma organização que esteja realizando o gerenciamento de projetos em qualquer plataforma ou sistema, como Primavera, Project Server, ou mesmo o velho e bom Excel.

..................................................

Para construir o processo de automação, o primeiro passo é exportar os projetos do Project Online (ou de qualquer que seja o sistema) para uma planilha de Excel, como no exemplo abaixo:


A planilha precisa então ser salva em uma biblioteca do SharePoint, para que seja possível obter os registros (linhas) através do Power Automate.

Outro ponto muito importante é mapear os tipos de campo (atributos) utilizados para categorizar os projetos no Project for the web. Como expliquei nesse vídeo, é possível criar campos de diferentes tipos (como Tabela de Pesquisa, Escolha, Texto Livre, etc.), então cada atributo (coluna) da planilha precisará ser tratado de maneira diferente quando da realização do mapeamento e conversão para sua contra-parte no Project for the web.

Uma vez no Power Automate, inicia-se o novo fluxo (disparado manualmente) e uma das ações iniciais deve ser a de listar as linhas presentes em uma tabela (assim como iniciar as variáveis que serão utilizadas para armazenar cada um dos atributos a serem passados como entrada quando do cadastramento do novo projeto):


Em seguida, para cada registro (linha) obtido da planilha Excel, deve-se tratar individualmente cada um dos seus atributos (colunas). Esse tratamento é necessário para que seja possível realizar a conversão adequada do valor do atributo, de modo que a informação possa estar de acordo com os parâmetros de entrada requeridos pelo Dataverse. A título de exemplo, vamos analisar o atributo (coluna) ProjectDirection da planilha – para melhor organizar os meus fluxos, eu gosto bastante de utilizar a ação Scope do Power Automate, pois isso me ajuda a colocar todas as ações de um determinado tópico em uma espécie de container:


O tratamento de dados a ser realizado na coluna ProjectDirection utilizará a ação de controle Switch do Power Automate para converter o texto oriundo da planilha (que é um texto livre) no valor respectivo da lista de escolha do campo de mesmo nome, o quel foi criado no Dataverse:


Nesse caso, ao observar os valores de escolha do campo Project Direction na tabela Projects, será possível identificar o valor que de fato é armazenado pelo sistema para cada uma das opções disponíveis:


Ou seja: quando o usuário escolhe a opção Information Technology na lista suspensa o Power Apps está, de fato, gravando o valor 884.760.000 na tabela. Dessa forma, a ação de controle Switch deverá ser configurada para converter o texto oriundo da planilha no valor específico correspondente, pois é esse o valor que deverá ser passado como parâmetro de entrada quando do cadastramento do projeto via processo de automação:


Uma lógica parecida se aplica quando da necessidade de realizar o tratamento de informações que são oriundas de uma tabela de pesquisa, como é o caso do campo Sponsor do exemplo atual. Nesse cenário, o atributo Sponsor tem como origem a tabela de pesquisa Users, e sendo assim deve-se pesquisar nessa tabela o usuário que corresponde ao endereço de e-mail informado na planilha:


Uma vez encontrado o usuário correspondente na tabela Users, é necessário registrar o seu ID interno para que este possa ser utilizado pelo processo de automação quando do cadastramento do projeto (note que o que deve ser passado como parâmetro é o ID do usuário, e não seu nome ou endereço de e-mail):


Após realizar o tratamento e o mapeamento dos campos conforme necessário, é chegado o momento de enfim criar o projeto no Dataverse. Porém (e parece sempre haver um porém!)... ao utilizar a ação adicionar uma linha do Power Automate e apontar para a tabela Projects, seremos apresentados a uma lista de campos obrigatórios que devem ser preenchidos para a criação de um novo projeto no Project for the web. Entre eles:

  • Calendar Id
  • Contracting Unit (Organizational Units)
  • Schedule mode
  • Work hour template (Work template)

Eu não fazia ideia de que era preciso ter posse dessas informações para criar um novo projeto no Project for the web via Power Automate 😕. Como não sabia os parâmetros para cada uma dessas informações, fiz o seguinte:
  • Criei um novo fluxo no Power Automate, disparado quando da criação de um novo projeto
  • Adicionei uma ação qualquer (por exemplo, iniciar uma nova variável), pois todo fluxo deve possuir pelo menos uma ação após seu disparo


Com isso, bastou criar manualmente um novo projeto no Project for the web para que esse fluxo auxiliar fosse disparado. Uma vez executado, foi possível colher os resultados do fluxo, os quais contemplam as informações que precisávamos para finalizar o processo de automação original:


De posse dos dados faltantes, basta regressar ao fluxo original para configurar os parâmetros:


Assim, quando tudo estiver pronto, basta iniciar o fluxo de maneira manual para que todos os projetos da planilha sejam devidamente cadastrados no Project for the web, respeitando e mantendo seus respectivos atributos:

...............................................

Confesso que essa não é, definitivamente, uma tarefa simples e corriqueira. Porém, foi muito gratificamente poder cadastrar todos esses 350 projetos de maneira automática – além de todo o aprendizado gerado a partir dessa necessidade.

Espero que esse post tenha sido útil de alguma forma. Até o próximo 😉.

segunda-feira, 17 de abril de 2023

Integração entre o Project Online e Azure DevOps


 Olá pessoal –

Há um certo tempo eu e meu amigo André Xavier entregamos uma palestra no evento Global Microsoft 365 Developer Bootcamp, e mesmo passados quase 3 anos do evento ainda hoje tenho desenvolvido soluções, através do Power Automate, que permitam a integração e a troca de informações entre o Project Online e o Azure DevOps.

Pretendo retomar esse assunto aqui no blog para compartilhar, com um pouco mais de detalhes, as lições aprendidas que venho coletando ao longo desse tempo a respeito da integração entre essas duas plataformas.

É tudo uma questão de processos

Antes de qualquer coisa, se você pretende iniciar um projeto que tenha como objetivo integrar essas duas plataformas, foque inteiramente no processo. Conversar e obter a maior quantidade possível de informações com os principais interessados na integração é fundamental para que, tecnicamente, a solução seja desenvolvida com sucesso. Procure entender aspectos como:

  • Quais times serão beneficiados (ou afetados) com a sincronização? É importante entender quem são os principais interessados pelo processo de integração, e como eles serão beneficiados/afetados. Não é incomum que, dentro de uma organização, diferentes times utilizem o Azure DevOps de diferentes maneiras, de modo que tentar criar um processo de integração único se torne complexo e problemático. Caso você tenha que suportar diferentes times, com diferentes metodologias e processos, talvez o melhor caminho seja construir uma integração individual para cada um dos times.
  • Qual o caminho a ser percorrido pelos dados? É preciso determinar se as informações serão coletadas no Azure DevOps para então alimentar o Project Online, ou se o caminho a ser percorrido será no sentido contrário. Ou, caso o processo desejado seja ainda mais complexo, pode ser que exista a necessidade de comunicação em duas vias, onde os dois sistemas trocarão informações entre si.
  • Quais informações serão coletadas e processadas na automação? O Azure DevOps permite que as equipes estruturem seu trabalho utilizando os mais variados componentes, como Bugs, Epics, Features, User Story e Tasks. Procure entender como esses componentes estão estruturados na sua organização (ou no seu cliente), e quais deles participarão de fato da integração. Além disso, para cada um dos componentes que eventualmente tenham de fazer parte do processo de integração, entenda quais atributos devem ser sincronizados (Trabalho Real/Restante, datas de Início e/ou Término, etc).
  • Qual será a periodicidade de sincronização? Lembre-se que, para editar um projeto no Project Online, é preciso efetuar o seu check-out... nesse contexto, um processo de sincronização que esteja configurado para ser executado muitas vezes ao longo do dia pode se tornar um pesadelo para os gerentes de projeto, uma vez que seus projetos podem ficar indisponíveis em diferentes momentos do dia, em decorrência do processo de automação. Uma recomendação é estabelecer uma periodicidade semanal (programada para acontecer no final de semana).

Crie campos personalizados

Uma vez que o roadmap do processo de sincronização tenha sido definido, o passo seguinte será criar os campos (colunas) personalizados para capturar os principais atributos que irão permitir a comunicação entre as duas plataformas – campos a serem criados tanto no Project Online quanto no Azure DevOps. A princípio, você deve pensar nos seguintes campos/colunas:

É claro que podem haver outros campos/colunas personalizadas que tenham de ser criadas nas plataformas, a depender de quais informações seja necessário coletar.

No azure devops, crie uma consulta robusta e confiável

Caso a necessidade da sua organização (cliente) seja a de sincronizar informações do Azure DevOps para o Project Online (trata-se da grande maioria dos casos), então você deve criar uma consulta extremamente robusta e confiável (no Azure DevOps).

Para melhor esclarecer o parágrafo anterior, é preciso entender que o processo de automação que é iniciado a partir do Azure DevOps precisa ser baseado em uma consulta – uma das primeiras ações do Power Automate é obter os resultados de uma consulta específica criada no ADO. Nesse sentido, ao configurar a consulta, é preciso garantir que seus parâmetros estejam muito bem definidos, afim de que apenas os dados necessário sejam submetidos à sincronização.

Uma consulta robusta e confiável também deve incluir parâmetros de governança e conformidade, evitando que dados contraditórios sejam trazidos ao processamento. Alguns exemplos:

  • Caso a sua organização (cliente) tenha a intenção de processar apenas o componente Tasks, configure a sua consulta para filtrar especificamente este item, deixando todos os demais de fora.
  • De modo geral, no Azure DevOps os usuários não tem a obrigatoriedade de preencher certas informações – como datas de início e término. Ao tentar sincronizar datas não preenchidas (em branco) com o Project Online o processo de automação gerará erros, e dessa forma é preciso configurar a consulta para que ela exclua do processamento tarefas que não possuam todas as informações a serem sincronizadas.
  • Da mesma maneira, o Azure DevOps permite que inconsistências sejam inseridas no âmbito de um componente – por exemplo, um usuário pode inserir uma data de término anterior à data de início. Como o Project Online jamais aceitará que uma tarefa tenha sua data de término definida para antes do seu início, é preciso configurar a consulta para excluir esse tipo de inconsistência.

Lembre-se de que é preciso rever os requisitos de negócio de maneira bem detalhada e meticulosa, para que seja possível identificar os possíveis erros que podem evetualmente acontecer no momento da sincronização, garantindo que eles sejam tratados pela consulta.

Tratamento de erros

Esteja preparado para aplicar o devido tratamento de erros ao processo de automação. Alguns dos erros mais comuns são:

  • Projetos em estado de check-out no momento da execução da automação
  • Tarefas (ou componentes) que fazem parte do processo de automação e que tenham sido eventualmente excluídas do cronograma (ou do board do Azure DevOps)
  • Tarefas com caracteres especiais nos seus nomes (! $ # * & ’ @ etc.)

...............................................

Bem, por hoje era isso. O objetivo era realmente trazer algo mais genérico a respeito do processo de automação, seus eventuais problemas e desafios – e não algo técnico que fosse descrever detalhadamente como estruturar toda a integração.

Se você ainda precisa de alguma ajuda fazer a sincronização funcionar aí na sua empresa, é só entrar em contato 😉.

sexta-feira, 30 de setembro de 2022

Limite de 300 registros na call REST api ao SharePoint

 Olá pessoal –

Meio que sem querer, me deparei recentemente com uma limitação do SharePoint no que se refere a quantidade de registros que podem ser obtidos através de uma call à sua api, ao utilizar o Power Automate.

Tanto aqui no blog quanto no meu canal do YouTube eu falo bastante sobre a utilização do Power Automate para turbinar o uso do Project Online, e na quase totalidade dos casos eu acabo utilizando a opção de realizar uma call ao SharePoint através da ação Send an HTTP Request to SharePoint, dada sua versatilidade e flexibilidade.

Pois bem... ao realizar um trabalho para um cliente, eu tinha a necessidade de obter a lista de todos os projetos salvos no Project Online, para então executar uma série de ações em alguns projetos específicos. Acontece que, ao estabelecer a conexão entre o Power Automate e o SharePoint, o número de registros obtidos do banco de dados era bem menor do que o número de projetos que de fato existiam no ambiente. Pra ser mais preciso, apenas 300 registros estavam sendo obtidos toda vez que o fluxo era iniciado:


Após bater um pouco a cabeça e entender que não havia nada nos filtros que estivesse limitando o número de registros obtidos pela consulta, percebi que havia uma limitação do próprio conector do SharePoint, que fixava em 300 o número máximo de registros que poderiam ser disponibilizados ao Power Automate a cada chamada feita à sua API.

Dessa forma, caso você esteja criando flows que obtenham dados do SharePoint, mantenha-se atento a essa restrição, pois ela pode acabar gerando alguns problemas não disponibilizando todos os registros que efetivamente deveriam ser processados. No meu caso específico, minha consulta estava obtendo dados da entidade projetos – porém, existem inúmeras outras entidades que tendem a ter um número muito maior de registros (como Tarefas e Atribuições, por exemplo).

Para resolver o meu problema, tive que limitar a consulta para um tipo de projeto específico, de modo a aplicar as ações apenas ao grupo de projetos que deveriam ser submetidos ao fluxo (conforme exemplo abaixo):


Entretanto, se no seu caso a necessidade seja executar a ação para todos os projetos independentemente do tipo, uma solução viável talvez seja agrupar os projetos por uma determinada categoria (Tipo, Proprietário, Status, Departamento...) e então executar as ações para cada um desses grupos individualmente, de modo que o limite de 300 registros não seja ultrapassado. A mesma lógica se aplica a qualquer outro tipo de registros a serem obtidos (por exemplo, ao tentar obter informações de tarefas, a melhor opção é primeiro filtrar por projeto, assim as tarefas serão obtidas de maneira individual, de acordo com o projeto ao qual pertençam, reduzindo assim o escopo de registros a serem processados na chamada).

Enfim, para você que desenvolve automações e utiliza o Power Automate e o Project Online (SharePoint) com frequência, fica aí uma lição aprendida que deve ser observada com atenção nos seus próximos desenvolvimentos 😉.

Um forte abraço e até a próxima!

quarta-feira, 31 de agosto de 2022

Project Web App Usage

 Project web app usage

Olá pessoal –

A Microsoft disponibiliza um importante material no seu site para tratar sobre as limitações do Project Online, no que se refere a desempenho e performance da plataforma – assim como da sua capacidade de armazenamento.

Um item importante da documentação se refere a cota destinada ao banco de dados do Project Online, que por padrão comporta 25GB por instância:


Esse limite de 25GB está relacionado diretamente com os objetos que existem no contexto do Project Online, como os Projetos (e seus respectivos cronogramas), Recursos, Tipos de Projeto da Empresa, Campos Personalizados da Empresa, etc. É importante lembrar que os sites de projeto e seus artefatos (documentos, riscos, problemas e demais listas customizadas) não entram nessa conta, pois são contabilizados no espaço total do SharePoint disponível na coleção de sites do PWA.

Ao navegar à página de Configurações Adicionais do Servidor do seu ambiente do Project Online, você poderá verificar se a utilização do banco de dados está se aproximando do limite de espaço disponibilizado:


É interessante observar que, nesse exemplo, mesmo estando próximo de atingir o limite de 25GB no que se refere aos objetos dentro do âmbito do Project Online, o consumo na camada de SharePoint é praticamente inexistente, como se pode verificar na imagem abaixo:


Fatores que contribuem para consumo do espaço

São vários os fatores que contribuem para um consumo elevado do banco de dados do Project Online. Entre eles, vale a pena citar:

  • Campos Personalizados de fórmula associados à entidade Tarefa


Caso a sua organização utilize um grande número de campos personalizados do tipo fórmula para a entidade de tarefas, vale a pena revê-los para identificar se todos os campos são necessários e devem ser mantidos no ambiente. Lembre-se que campos do tipo fórmula são calculados e processados toda vez que um cronograma é aberto, salvo e publicado.

  • Projetos com uma longa duração

Veja o exemplo abaixo:


O primeiro projeto dessa lista tem uma duração total de 26.163 dias , com a data final prevista para 2120 💀 ! Considerando que estou escrevendo esse post em 2022, serão necessários mais 98 anos para que este projeto seja finalizado – isso, é claro, se tudo sair conforme o plano atual 😊.

A depender da quantidade de tarefas no cronograma desse projeto, serão necessárias milhares (senão milhões) de linhas para registrar e armazenar todas as atribuições, a distribuição das horas, dos custos, das informações de linha de base, etc. Adicionalmente, o próprio processamento das informações pelo Microsoft Project (quando da abertura, do salvamento e da publicação do projeto) ficará comprometido, aumentando o risco de corrupção do arquivo. Abaixo é possível ver um exemplo de 4 cronogramas reais com mais de 35 mil atribuições, um número extremamente alto e definitivamente não recomendável:


Em casos assim, o recomendado seria decompor os cronogramas em partes menores e mais gerenciáveis, que poderiam estar conectadas entre si. Dessa forma, quando uma fase do projeto estiver concluída, o cronograma pode ser arquivado adequadamente, sem comprometer as etapas futuras.

Apenas para se ter uma ideia do volume de dados processados e armazenados, veja a quantidade de atribuições para cada um dos projetos da tabela acima, numa hierarquia de ano/mês:


Agora pense na quantidade de transações que são necessárias para processar esses dados a cada vez que o cronograma é aberto, salvo ou publicado.

Objetos adicionais

Fique atento também à quantidade de objetos adicionais que eventualmente existam no seu ambiente. Mesmo que não haja um processamente explícito desses elementos, eles podem ter uma contribuição significativa no consumo de espaço do seu banco de dados. Entre esses objetos, vale a pena destacar:

  • Demais Campos Personalizados da Empresa e Tabelas de Pesquisa
  • Calendários Empresariais
  • Modos de Exibição Empresariais
  • Tipos de Projeto da Empresa
  • Grupos e Categorias de Segurança personalizados
  • Quantidade de Projetos e Recursos
  • Quantidade de Timesheets (Quadros de Horários)

...........................................................................................................

Na posição de administrador do Project Online, estabeleça um cronograma de revisões periódicas no seu ambiente para garantir que a quantidade de dados utilizados esteja em acordo com o volume de espaço disponibilizado, para não correr nenhum risco de ter o ambiente paralisado ou a utilização temporariamente suspensa.

Espero que tenha ajudado, e até a próxima!

quarta-feira, 29 de junho de 2022

Relatório de projetos em check-out

 Olá pessoal –

Há um certo tempo eu venho falando aqui no blog sobre as diferentes possibilidades e opções de check in e check out no Project Online através da utilização do Power Automate. Entender esse conceito é muito importante para aqueles que precisam automatizar as rotinas do escritório de projetos, uma vez que na grande maioria das vezes é preciso colocar um projeto em edição (check out) para que então seja possível realizar ações de atualização em suas propriedades.

Como existem incontáveis cenários de automatização no Project Online, assim como existem também inúmeras restrições e impedimentos que podem ser aplicáveis de acordo com a característica de cada negócio, pode haver situações nas quais forçar o check in dos projetos não seja uma opção.

Dessa forma, através da utilização da API do Project Server é possível criar um relatório (no Excel ou no Power BI) que identifique dinamicamente os projetos em check out.

Para construir o relatório, utilizando a plataforma de sua preferência, efetue uma conexão à API do Project Server da sua organização:

https://<URL da sua organização>.sharepoint.com/sites/pwa/_api/ProjectServer

Ao se conectar ao ambiente do Project Online, clique na opção de expansão da tabela Projects:


Em seguida, selecione os campos que deseja utilizar no relatório. Como sugestão, você pode utilizar os seguintes campos:

  • Id
  • Name
  • CheckedOutDate
  • IsCheckedOut
  • CheckedOutBy



Em seguida, você deverá filtrar todos os projetos para os quais o campo IsCheckedOut é igual a TRUE:


Caso você queira saber quem é o gerente de projeto que efetuou o check out em cada um dos projetos listados, você poderá expandir a coluna CheckedOutBy:


Assim você terá em mãos todos os campos necessários para gerar o relatório, e então poderá entender quais são os projetos em check out, quem são os responsáveis pelo check out e até há quanto tempo cada projeto encontra-se bloqueado:


Por hoje era isso. Espero que ajude 😊


sábado, 30 de abril de 2022

Publicando os riscos do projeto no Microsoft Teams

 Olá pessoal –

Este post é uma continuação de uma publicação anterior, onde comentei sobre as possibilidades de integração entre o Project Online e o Microsoft Teams. Dessa vez, nosso objetivo será comunicar a equipe de projetos, através dos Adaptative Cards, sempre que um novo risco for criado em qualquer um dos projetos que façam parte do nosso portfolio.

Contexto e configurações iniciais

É sabido que as organizações podem configurar o Project Online com um ou mais modelos de site, de modo a garantir que a plataforma se encarregue de criar um novo site padronizado sempre que um novo projeto for iniciado. Para assegurar que a automação funcione corretamente, convém criar, no modelo de site, uma nova coluna na lista de riscos para capturar o status da automação. Essa coluna pode ser de texto livre e, idealmente, deveria ficar oculta no formulário de cadastro/edição de riscos, para evitar que usuários a manipulem desnecessariamente.


O flow

Criada a coluna auxiliar, vamos ao desenvolvimento do flow. Como não é possível monitorar todos os sites existentes no Project Online para que o gatilho do processo de automação seja disparado sempre que um novo risco for criado, a maneira mais adequada de organizar o processo de automação é criar um fluxo agendado, que seja disparado diariamente e então faça a varredura de todos os sites para verificar se novos riscos foram criados. A imagem abaixo apresenta um resumão de como o fluxo está estruturado, mas iremos entrar em detalhe sobre cada uma das ações em seguida:


De início, temos o gatilho do fluxo. No meu exemplo, estou disparando a automação de modo manual, mas é claro que a maneira mais conveniente seria através de um gatilho agendado para acontecer diariamente. Em seguida, duas variáveis são iniciadas para que seja possível capturar a URL do ambiente do Project Online e também  a URL exclusiva de cada site para qual o processo de automação será aplicado. O próximo passo irá utilizar a já consagrada ação Send an HTTP Request to SharePoint para escanear todos os projetos disponíveis no Project Online, assim como os endereços (URLs) dos seus respectivos sites:


A partir daí lançamos mão da ação Apply to each, pois a varredura na lista de riscos deve acontecer para cada um dos projetos encontrados. As instruções utilizadas foram:

Em Apply to each, na área Select an output from previous steps:

Body('Get_Projects')?['value']

Em Site Address:

Items('Apply_to_each')?[ 'ProjectWorkspaceInternalUrl']

É importante também notar que um filtro está sendo aplicado à consulta, de modo a obter apenas os riscos para os quais a coluna auxiliar Status Automação não seja igual a (ne) ‘Processado’:


Uma vez obtidos todos os riscos que ainda não foram processados no site de projetos em questão, a variável Project Site URL está sendo definida com o endereço do site (ou seja, nesse momento é definida a URL do site do contexto para o qual o processo de automação está sendo processado).

Em seguida, temos uma nova ação Apply to each. Essa ação é necessária porque, em cada um dos sites analisados, podemos ter um ou mais riscos que ainda não foram processados pela automação – e, dessa forma, para cada um desses registros o processo deverá acontecer. Dentro do Apply to each 2, a instrução utilizada foi:

Body('Get_Risks')?['value']

Assim, uma postagem utilizando os adaptative cards é realizada no Microsoft Teams para garantir que os membros do PMO e demais interessados sejam informados de que um novo risco foi criado:


Logo após a publicação no Teams informando sobre a criação do novo risco, é necessário utilizar novamente a ação Send an HTTP Request to SharePoint para atualizar a coluna auxiliar Status Automação, informando-a de que esse risco específico não mais precisa ser processado na automação na próxima vez em que ela for disparada:


Note que essa é uma ação bem específica, que não está sendo aplicada no contexto do Project Online, mas sim do próprio SharePoint (pois não é algo que está alterando uma propriedade do projeto, mas sim do risco, que pertence a um site de SharePoint).

A ação permite fazer uma chamada ao site do projeto, procurando especificamente pela lista de riscos e, dentro dessa lista, pelo ID do risco que está sendo atualizado:

items('Apply_to_each_2')?['ID']

Em seguida, na área de body, é passada a instrução para atualizar a coluna Status Automação: 

{

"__metadata": {

"type": "SP.Data.RisksListItem"

},

"Status_x0020_Automa_x00e7_x00e3": "Processado"

}

...........................................................................................................................................

Assim, quando um novo risco for criado, a postagem será feita no canal especificado no Microsoft Teams:

....................................................................................................

E por hoje é só pessoal. Espero que gostem desse post, e até o próximo!