Gerencie tópicos, revisão e status de publicação no Google Sheets
Gerencie cada artigo como uma linha e separe redação, revisão, aprovação e publicação. Abrange importação de um CSV local, listas suspensas, filter views, permissões de compartilhamento e histórico de versões, além de configurar um fluxo para atualizar manualmente os arquivos do site após a aprovação.
Conteúdo verificado 2026.09.19Inclui arquivos de exemplo
Ver o sumário
A tradução foi feita com IA. Confira o código, as unidades e os valores junto com o original. A revisão por falantes nativos de cada idioma ainda não foi concluída. English
Para quem éRedatores e revisores que mantêm juntos um pequeno site de tutoriais ou documentos de conhecimento da equipe
Preparação
Prepare os arquivos baixados content-register.csv e README.txt.
O administrador decide quais contas do Google a equipe usará e quem será o proprietário do arquivo. Nenhuma conta foi criada ou conectada para este artigo.
Combine os papéis de redação, revisão e publicação e os critérios para alteração do status.
01Coloque a próxima ação de um artigo em uma única linha
Com apenas uma lista de tópicos, é difícil saber qual draft está em revisão e o que está bloqueando a publicação. Este exemplo vincula article ID, audience, deliverable, writer, reviewer, status, evidence, privacy check, approval date, published URL e release version em uma única linha. O article ID permanece o mesmo mesmo que o título mude e é usado como chave para localizar os registros novamente.
02Primeiro defina o significado das colunas e dos statuses
Grupo de colunas
O que registrar
Article ID · title · audience · deliverable
Qual problema é resolvido, para quem e o que é entregue
Writer · reviewer · review due date
Papéis e datas a verificar
Status · next action
A etapa atual e o que a próxima pessoa deve fazer
Evidence · privacy check
Fontes oficiais ou uma descrição do exemplo sintético, e o resultado da verificação
Approval date · published URL · release version
Quando foi aprovado e o resultado que realmente foi publicado
Use apenas um destes statuses: idea, drafting, in review, changes requested, approved, published, on hold. approved é o registro da equipe de que a revisão terminou, e published é o registro de que o conteúdo foi aplicado ao site e o resultado foi verificado. Essa distinção é uma regra operacional que definimos, e não um sistema de aprovação incorporado ao Sheets.
03Importe o CSV e configure dropdowns
O administrador prepara uma nova planilha de acompanhamento no Google Sheets e seleciona o content-register.csv local em File > Import. Verifique import location e separator e não substitua acidentalmente uma planilha de acompanhamento existente.
Após a importação, verifique se as 14 header columns, as 4 sample rows, o texto em coreano e as colunas approval date e published URL vazias foram preservados. A importação real no Google Sheets não foi testada para este artigo.
Verifique se review due date e approval date são reconhecidos como datas e exiba-os como YYYY-MM-DD. Mantenha article ID como identificador de texto.
Selecione as data cells da coluna status e registre os sete statuses em Insert > Dropdown ou Data > Data validation. Permita apenas um status por linha.
Para a coluna privacy check, registre not checked, needs changes e done. Verifique também a configuração para valores que não estejam na dropdown list.
Depois de verificar o comportamento com a amostra, remova as linhas sintéticas ou mantenha-as em uma practice copy separada para que não sejam confundidas com registros reais.
A ajuda oficial do Google descreve file import e cell dropdowns como recursos separados. Um CSV carrega apenas valores, portanto você deve adicionar essas configurações após a importação. Não descreva o arquivo como se já tivesse automatic syncing ou connections configurados.
04Use filter views para ver apenas o seu próprio trabalho
Um reviewer pode querer ver primeiro as linhas com status in review, e um writer pode querer ver primeiro suas próprias changes-requested rows. No Sheets para desktop, use Data > Create filter view, escolha os critérios de status e owner e salve views como “Awaiting review” e “My changes”. Um filter normal também pode ficar visível para outros usuários de um arquivo compartilhado, portanto use filter views para organizar o trabalho individual.
Um filter oculta linhas. Não o trate como exclusão de linhas ou restrição de permissions.
Ordenar uma única coluna isoladamente pode desalinhá-la de titles e owners, então verifique se todo o managed range está incluído no sort.
Verifique separadamente também as linhas com due date em branco. Não aparecer em um filter não significa que o trabalho esteja concluído.
Um temporary filter view criado com view permission pode não ser salvo, portanto verifique o management role necessário e se ele foi salvo.
05Gerencie permissões de compartilhamento e version history
O proprietário do arquivo deve considerar manter general access como restricted e adicionar pessoas específicas. Writers podem ser editors, reviewers que apenas deixam feedback podem ser commenters e stakeholders que apenas leem podem ser viewers. Commenters não podem alterar diretamente o status de uma célula, portanto defina que o editor que recebe o review feedback registra o status e o approval date. O administrador concede permissions de acordo com as necessidades reais de trabalho.
Usuários com edit permission podem verificar estados anteriores e quem fez alterações no version history, além de nomear versões em pontos importantes. Isso ajuda a localizar o estado logo antes da aprovação, mas não é o mesmo que o version history dos site files. Restaurar uma versão anterior pode desfazer outras edições, portanto verifique o impacto antes de fazer isso. Baixar um CSV não preserva sharing permissions nem version history.
06Fluxo manual da aprovação até a atualização do site
O reviewer verifica sources, example results e sensitive information e deixa change requests ou approval feedback.
Com base no draft que incorpora o feedback, o editor altera o status para approved e registra o approval date.
O publisher aplica manualmente o approved content ao content JSON e aos download assets do site. Este exemplo não tem automatic CMS sync do Sheets para o site.
Verifique structure, links, examples e page display do artigo alterado e depois faça deploy. Se o audience do site for owner-private, o resultado também permanece dentro desse access scope.
Depois de verificar a deployed page, registre o published URL real e a release version e altere o status para published. Se public publishing for necessário, o audience do site deve ser alterado para public e o access verificado separadamente.
Quando uma mudança for necessária, mantenha o mesmo article ID, mova o status de volta para changes requested ou in review e registre o motivo em next action.
Nenhum comportamento automático como “alterar o status para approved no Sheets atualiza o site” foi implementado. Esta tracking sheet é um registro no qual as pessoas relacionam quem aprovou qual draft e em qual release ele entrou.
07Verifique as regras operacionais com a amostra sintética
Sample
Status · check
Ação necessária agora
EX-001
Idea / not checked
Escrever o draft do exemplo sintético
EX-002
Drafting / not checked
Preencher os handover items
EX-003
In review / needs changes
Revisar novamente após remover internal paths
EX-004
Approved / done
Aplicar ao JSON, verify e deploy; published URL ainda está vazio
EX-004 também não tem published URL nem release version, portanto não é contado como published. Da mesma forma, adicionar apenas um link não permite pular o review. Antes da publicação, uma pessoa verifica se approval date, evidence e privacy check result estão todos presentes. O CSV não contém formulas ou automation que imponham esses julgamentos.
Verifique se o mesmo article ID não aparece duas vezes.
Verifique se o link real nas linhas com status published abre e corresponde ao draft correto.
Limpe os filters para confirmar que linhas on-hold, undecided ou unassigned não estão ausentes.
Verifique juntos a sharing list e general access.
Em uma test copy, verifique quais roles podem ver version history e quais só podem deixar comments.
08Downloads e escopo da verificação
content-register.csv é um template local com 14 colunas e 4 linhas de dados sintéticos. README.txt, column-guide.txt e workflow-checklist.txt contêm as configurações a aplicar após a importação e as status rules. Foram verificados a UTF-8 encoding do arquivo local, row and column counts, duplicate article IDs, allowed statuses e os blank published URLs das amostras. A importação real no Google Sheets e as operações de dropdown, permission e version history não foram testadas.
Nenhuma conta ou Google Drive files foram criados ou conectados, e o site checkout não foi modificado. Em organization accounts, o sharing scope pode ser limitado por admin policy. As páginas oficiais de ajuda foram verificadas em 19 de setembro de 2026, e os menu labels podem variar conforme display language e product updates.
Registro de execução e verificação
@oai/artifact-tool local e verificações CSV/JSON com Python; fontes oficiais verificadas em 2026-09-19
Foram verificados a UTF-8 encoding do CSV local, 14 columns, 4 rows de dados sintéticos, duplicate article IDs e status values
Foi verificada a article JSON structure e se os sample statuses e next actions correspondem
Foram verificados o salvamento e a nova leitura dos local table values
Limites da verificação
A importação real no Google Sheets e as operações de dropdown, filter, sharing e version history não foram verificadas
Nenhuma Google account ou Drive file foi criada ou conectada
Automatic site sync após aprovação no Sheets não está implementado; manual update, verification e deployment são necessários
O código de exemplo, os nomes de arquivos e as chaves de entrada são mantidos como no original. Consulte também os comandos e os procedimentos de conferência do texto traduzido.
Material de prática original · Guarde os arquivos originais separadamente antes de executar.
Fontes de referência
As explicações e os exemplos são de elaboração própria. Os comportamentos e conceitos relacionados podem ser consultados nas fontes oficiais abaixo.
Em vez de parar em mais um resumo da reunião, separe o trabalho acordado dos itens em aberto. Transforme notas sintéticas de reunião em uma lista com responsáveis, prazos, entregáveis e evidências de conclusão, e escreva uma solicitação para IA que ajude na mesma tarefa.
Defina uma convenção simples de nomes de arquivos para a equipe, teste-a em uma pasta sintética e gere um relatório de revisão sem renomear nem excluir nada. O verificador separa erros estruturais, datas inválidas e extensões não suportadas.
Transforme release notes brutas em uma entrada de changelog que separe mudanças de ações obrigatórias do usuário e etapas de verificação. Uma atualização sintética de software mostra como tornar uma nota de versão útil para alguém que não fez a alteração.
Transforme notas de passagem de projeto em uma lista estruturada que registre o que precisa ser transferido, quem é responsável, onde está armazenado e o que permanece sem solução. Um pequeno exemplo sintético mostra como detectar responsáveis, locais e detalhes de pendências ausentes antes da passagem.