Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: Tudo
Use esses cenários para decidir se o SharePoint Embedded se adapta ao seu aplicativo. Cada um começa com um problema que os desenvolvedores realmente enfrentam, mostra por que as abordagens usuais ficam aquém e explica por que o SharePoint Embedded é a escolha certa.
Observação
Este artigo não é uma lista completa. Cada cenário mostra uma maneira de combinar recursos do SharePoint Embedded para resolver um problema comum.
Cenário: armazenar arquivos para um aplicativo SaaS multilocatário
O problema
Você cria um produto SaaS multilocatário, como o gerenciamento de contratos para equipes jurídicas corporativas. Seu maior bloqueador é o armazenamento de arquivos. Os clientes corporativos não aceitarão que os documentos deles permaneçam no seu armazenamento. Suas equipes de TI desejam aplicar suas próprias políticas de segurança e conformidade, como prevenção contra perda de dados (DLP) e regras de retenção. Você ainda precisa ter controle total dos arquivos do seu aplicativo: criar, ler, organizar, conceder permissão e excluir, tudo por meio de APIs.
Por que as abordagens usuais ficam aquém
- Seu próprio armazenamento de blobs coloca os dados do cliente fora do locatário do cliente, o que a TI corporativa rejeita.
- As APIs de armazenamento de arquivos concorrentes usam licenciamento por estação e dão ao administrador do cliente pouco controle de política.
Por que o SharePoint Embedded
O SharePoint Embedded armazena os arquivos de cada cliente dentro do locatário do Microsoft 365 desse cliente, enquanto seu aplicativo mantém controle programático total:
- O conteúdo está no locatário do Microsoft 365 do cliente, não no seu.
- O armazenamento usa contêineres de armazenamento de arquivos, uma unidade somente de API que seu aplicativo controla.
- A superfície da API é Microsoft Graph; Seu aplicativo é proprietário de toda a experiência do usuário.
- O conteúdo herda a conformidade do locatário do cliente com o Microsoft Purview, incluindo DLP e retenção.
Consulte Escolher um modelo de aplicativo e Criar e gerenciar contêineres.
Cenário: adicionar a coautoria do Office ao seu aplicativo
O problema
Você tem um aplicativo personalizado e sua principal solicitação de recurso é "deixe-me editar documentos do Office da mesma maneira que estou acostumado". Hoje você armazena arquivos e distribui links para download. Talvez você até use um host WOPI (Web Application Open Platform Interface). Mas seus usuários desejam abrir um arquivo do Word ou Excel e cocriminá-lo em tempo real. Eles esperam Salvamento Automático, histórico de versão e compartilhamento, além da experiência completa do Office para a Web, Office para área de trabalho e Microsoft 365 para dispositivos móveis.
Por que as abordagens usuais ficam aquém
- Criar a coautoria por conta própria com tipos de dados replicados sem conflitos leva meses e ainda não tem renderização nativa do Office.
-
Um mecanismo de colaboração que não seja da Microsoft não abre
.docxe.xlsx.pptxcom fidelidade total.
Por que o SharePoint Embedded
Armazene os arquivos em um contêiner do SharePoint Embedded e inicie-os no Office. Seu aplicativo é vinculado ao mesmo serviço do Office que o Microsoft 365 usa, portanto, você não cria um mecanismo de colaboração:
- Coautoria em tempo real no Office para a Web e clientes da área de trabalho do Office.
- Salvamento Automático e histórico de versões automáticas do Word, Excel e PowerPoint.
- Compartilhamento por meio de links compartilháveis, além de @mentions usuários licenciados.
- Níveis de acesso com escopo: Qualquer pessoa, People em sua organização, pessoas específicas e People com acesso existente.
A edição é aberta no Office, não dentro do seu aplicativo. O Office para a Web é aberto em uma nova guia ou janela do navegador, e os clientes da área de trabalho são abertos em seus próprios aplicativos. Para manter os usuários na interface do usuário do seu aplicativo, insira uma visualização de arquivo somente leitura; use o Office Launch para edição.
Confira Adicionar a coautoria do Office sem criá-la e Abrir arquivos do Office do seu aplicativo.
Cenário: fundamentar um agente de IA em conteúdo corporativo
O problema
Você constrói um agente interno "pergunte à base de dados de conhecimento" em milhares de documentos espalhados por compartilhamentos de arquivos e um sistema herdado. Você deseja consolidá-los, torná-los pesquisáveis e usá-los para fundamentar um grande modelo de linguagem. Sua equipe de segurança rejeita copiar tudo em um banco de dados vetorial externo e o conteúdo deve manter seus controles de retenção e descoberta eletrônica.
Por que as abordagens usuais ficam aquém
- Um banco de dados de vetor externo move o conteúdo para fora do locatário e quebra o limite de conformidade.
- O armazenamento de blobs mais um índice personalizado força você a recriar o DLP, a retenção e a descoberta eletrônica por conta própria.
Por que o SharePoint Embedded
Armazene os documentos em contêineres incorporados do SharePoint e mantenha seu agente no lugar:
- O conteúdo permanece no locatário do Microsoft 365 do cliente.
- A descoberta de conteúdo é uma configuração do tipo de contêiner — o modelo que define os contêineres do seu aplicativo. Ela determina se o conteúdo do SharePoint Embedded será exibido nas experiências do Microsoft 365, incluindo o Copilot. A governança de locatário controla essa configuração, portanto, um aplicativo não pode expor o conteúdo alterando sua própria configuração.
- Recupere conteúdo com a API de Pesquisa da Microsoft, com escopo definido pela ID de tipo de contêiner (
ContainerTypeId) ou com uma fonte de conhecimento do Microsoft Foundry. - A DLP (prevenção contra perda de dados) do Microsoft Purview, a retenção e a Descoberta Eletrônica se aplicam. Nada é exposto ao Copilot até que a detectabilidade seja habilitada no tipo de contêiner.
Consulte IA terrestre sem um banco de dados de vetor externo e Configurar o SharePoint Embedded como uma fonte de conhecimento do Foundry.
Cenário: executar um armazenamento de documentos compatível somente com API
O problema
Seu aplicativo coleta documentos de clientes, dentro ou fora da sua organização, como parte de um fluxo de trabalho. Os exemplos incluem anexar evidências a um pedido de hipoteca ou verificar um documento de identidade. Você deseja uma experiência de upload simples, além de armazenamento e conformidade do Microsoft 365, sem fornecer aos usuários acesso ao seu locatário.
Por que as abordagens usuais ficam aquém
- Os sites do SharePoint Online expõem uma interface que os usuários podem navegar, o que você não deseja.
- O armazenamento de blobs permite que você crie a lixeira, a restauração, a pesquisa e a conformidade por conta própria.
Por que o SharePoint Embedded
O SharePoint Embedded oferece um repositório de documentos somente API com recursos internos do Microsoft 365:
- Somente API por meio do Microsoft Graph: cada operação de arquivo e contêiner usa o Microsoft Graph, sem nenhuma interface do usuário do SharePoint para os usuários ignorarem.
- Ciclo de vida completo do conteúdo: upload e download, estrutura de pastas e controle de versão.
- Exclusão temporária de dois níveis: os itens excluídos vão para uma lixeira de contêiner da qual você pode restaurar e os contêineres excluídos são movidos para uma coleção de contêineres excluída que permanece restaurável por 93 dias antes da limpeza permanente.
- Pesquisar por meio da API de Pesquisa da Microsoft, com escopo para os contêineres do seu aplicativo.
- Conformidade do Microsoft Purview herdada do locatário consumidor: DLP, políticas de retenção, rótulos de confidencialidade e Descoberta Eletrônica.
- Os usuários finais do seu aplicativo não precisam de uma licença do Microsoft 365 para operações básicas de arquivo.
Consulte Carregar, baixar e gerenciar arquivos e Arquivo e restaurar contêineres.