---
title: "Aprobaciones entre Teams y ERP: ¿qué arquitectura encaja?"
description: "Guía documental para elegir Power Automate, Copilot Studio, desarrollo a medida o, de forma opcional, n8n en un flujo de aprobación de ERP desde Teams."
updated: 2026-09-06
language: es
page_type: scenario
human_url: "https://kiia.cloud/es/escenarios/teams-erp-aprobaciones/"
---

Usa Power Automate para una aprobación determinista si Microsoft 365 y el acceso al ERP encajan. Añade un agente solo cuando la conversación cambie el trabajo.

> Esta guía se basa en documentación oficial de los proveedores, revisada el 6 de septiembre de 2026. Kiia no ha ejecutado un benchmark común ni un piloto de estas alternativas. Antes de aplicar la recomendación hay que comprobarla en tu entorno de Microsoft, con la edición del ERP y la política de aprobación de tu empresa.

## Respuesta breve

Empieza por Power Automate cuando un evento del ERP pueda iniciar un flujo determinista, estén disponibles las lecturas y escrituras necesarias, y Teams sea el lugar donde una persona aprueba o rechaza. Microsoft documenta el uso de aprobaciones en Teams con un conector personalizado para aplicaciones empresariales.

Valora Copilot Studio cuando las personas necesiten un agente conversacional para localizar una solicitud, explicar su contexto, recopilar información ausente o invocar el flujo de aprobación como herramienta. Copilot Studio añade esa conversación y coordina las acciones del agente. Para una regla de aprobación fija, el flujo puede funcionar sin esa capa.

Usa desarrollo específico cuando el proceso requiera estado complejo y duradero, una interfaz del ERP no compatible, controles estrictos de rendimiento o disponibilidad, lógica propia o una interfaz operativa de uso diario. Una arquitectura híbrida es válida: el código puede gestionar el estado mientras Power Automate se ocupa de la aprobación y los avisos en Teams.

Mantén n8n como candidato opcional cuando el flujo esté orientado a APIs, atraviese varios sistemas ajenos a Microsoft y exista un equipo técnico capaz de operar el alojamiento o instancia gestionada, credenciales, actualizaciones, monitorización y recuperación. Que el equipo use Teams no basta para decidir qué herramienta debe coordinar el flujo.

## El flujo que se compara

<div class="flow-scroll" role="region" aria-label="Diagrama de aprobación desplazable" tabindex="0">
<svg class="flow-diagram" viewBox="0 0 880 250" role="img" aria-labelledby="flow-title-es flow-desc-es" xmlns="http://www.w3.org/2000/svg">
  <title id="flow-title-es">Flujo ilustrativo de aprobación entre Teams y ERP</title>
  <desc id="flow-desc-es">Un evento del ERP se valida, se envía a una aprobación humana en Teams, se escribe de vuelta en el ERP y pasa a una cola de excepciones si no puede completarse.</desc>
  <defs><marker id="arrow-es" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="7" markerHeight="7" orient="auto"><path d="M0 0 10 5 0 10Z" fill="#0071e3"/></marker></defs>
  <g fill="none" stroke="#0071e3" stroke-width="3" marker-end="url(#arrow-es)"><path d="M180 91H250"/><path d="M400 91H470"/><path d="M620 91H690"/><path d="M545 130V179"/></g>
  <g font-family="Arial, sans-serif" text-anchor="middle">
    <g><rect x="30" y="50" width="150" height="82" rx="14" fill="#fff" stroke="#d2d2d7"/><text x="105" y="82" font-size="14" font-weight="700" fill="#1d1d1f">Evento en ERP</text><text x="105" y="105" font-size="12" fill="#6e6e73">pedido o propuesta</text></g>
    <g><rect x="250" y="50" width="150" height="82" rx="14" fill="#fff" stroke="#d2d2d7"/><text x="325" y="82" font-size="14" font-weight="700" fill="#1d1d1f">Validar y dirigir</text><text x="325" y="105" font-size="12" fill="#6e6e73">reglas y responsable</text></g>
    <g><rect x="470" y="50" width="150" height="82" rx="14" fill="#fff" stroke="#d2d2d7"/><text x="545" y="82" font-size="14" font-weight="700" fill="#1d1d1f">Aprobar en Teams</text><text x="545" y="105" font-size="12" fill="#6e6e73">decisión humana</text></g>
    <g><rect x="690" y="50" width="160" height="82" rx="14" fill="#fff" stroke="#d2d2d7"/><text x="770" y="82" font-size="14" font-weight="700" fill="#1d1d1f">Escribir en ERP</text><text x="770" y="105" font-size="12" fill="#6e6e73">decisión + ID auditoría</text></g>
    <g><rect x="465" y="180" width="160" height="48" rx="14" fill="#1d1d1f"/><text x="545" y="209" font-size="13" font-weight="700" fill="#fff">Cola de excepciones</text></g>
  </g>
</svg>
</div>

<small class="evidence-note">Arquitectura ilustrativa. No contiene volumen, latencia, ahorro ni tasa de éxito medidos.</small>

El proceso común es:

1. Un pedido, presupuesto, solicitud de compra o cambio de dato maestro alcanza un estado definido en el ERP.
2. La integración valida el identificador, estado actual, importe, moneda y campos obligatorios.
3. Una política documentada selecciona a quien aprueba y evita solicitudes duplicadas.
4. Teams presenta el contexto mínimo necesario para una decisión humana.
5. La decisión, persona, fecha e identificador de correlación se escriben en el sistema de registro.
6. Los datos ausentes, esperas agotadas, estados incompatibles y fallos de escritura pasan a una cola de excepciones con responsable.

## Comparación de arquitecturas

| Opción | Mejor encaje | Qué debe comprobarse | Responsable operativo |
|---|---|---|---|
| Power Automate | Aprobación determinista; ya existe administración de Microsoft 365; el ERP dispone de conector, API HTTP o conector personalizado mantenible | Lectura y escritura del ERP, clase y licencia del conector, disponibilidad de Approvals/Workflows en Teams, identidad de servicio, esperas, reintentos y política del entorno | Responsable de Power Platform y responsable del proceso |
| Copilot Studio | Una conversación debe localizar, explicar, completar o iniciar solicitudes; el flujo determinista puede invocarse como herramienta | Si un agente mejora la tarea, permisos de conocimiento y datos, revisión humana, modelo de capacidad y alternativa segura cuando no pueda actuar | Responsable del agente, de Power Platform y del proceso |
| Desarrollo específico | Estado complejo, reglas propias, interfaz no compatible, controles estrictos o interfaz operativa propia | Autenticación, contrato del ERP, alojamiento, despliegue, observabilidad, soporte, pruebas y coste de ciclo de vida | Responsable de producto o ingeniería y del proceso |
| n8n, opcional | Flujo entre varias APIs; la empresa tiene capacidad técnica y quiere control explícito del workflow | Comportamiento de APIs de ERP y Teams, propiedad de instancia y credenciales, licencia, seguridad, actualizaciones, escalado, monitorización y recuperación | Responsable de integración o plataforma y del proceso |

La comparación no asigna puntuaciones. Descartamos una opción si no permite una escritura obligatoria o exige mover datos de una forma prohibida.

## Datos que pueden cambiar la recomendación

- ¿El ERP ofrece el evento y la escritura exactos en la edición y región de la empresa?
- ¿Puede actuar una identidad de servicio o el flujo dependería de la cuenta de una persona?
- ¿La decisión sigue una política estable o necesita conversación y pruebas adicionales?
- ¿Debe responder todo el mundo, se puede delegar y qué ocurre al agotar el plazo?
- ¿Qué campos pueden mostrarse en Teams y dónde se guardan los adjuntos?
- ¿Qué evita que un evento repetido cree dos aprobaciones o escriba dos veces la decisión?
- ¿Quién vigila los fallos, concilia pendientes, rota credenciales y aprueba cambios?
- ¿Qué disponibilidad y tiempo de recuperación exige el proceso?

## Validación mínima antes de una propuesta

Prueba el flujo con datos sintéticos o aprobados. Incluye una lectura, una aprobación, un rechazo y una escritura de vuelta. Comprueba también qué ocurre ante un evento duplicado, campos ausentes, un tiempo de espera agotado y un fallo al escribir en el ERP. Revisa el estado final en el ERP: el flujo puede terminar sin errores y aun así dejar incompleto el proceso de negocio.

En cada prueba registra la edición y el entorno, la operación del conector o API, la identidad utilizada, las marcas de tiempo y el ID de correlación. Incluye los reintentos, quién resolvió las excepciones y el resultado. Esos datos permiten estimar la implementación y el coste de operar esa arquitectura.

## Fuentes y límites

- Microsoft documenta las [aprobaciones en Teams con conectores personalizados](https://learn.microsoft.com/es-es/power-automate/teams/approvals-custom-connector) y la [experiencia nativa de aprobaciones](https://learn.microsoft.com/es-es/power-automate/teams/native-approvals-in-teams).
- La [referencia del conector de Microsoft Teams](https://learn.microsoft.com/es-es/connectors/teams/) recoge requisitos y límites por operación que deben revisarse para la acción elegida.
- Microsoft describe los [flujos de agente de Copilot Studio](https://learn.microsoft.com/es-es/microsoft-copilot-studio/flows-overview), incluidas acciones deterministas, aprobaciones humanas, conectores y consumo de capacidad.
- n8n publica guías de [alojamiento propio](https://docs.n8n.io/hosting/) y [auditoría de seguridad](https://docs.n8n.io/hosting/securing/security-audit/); operar la instancia sigue formando parte de la decisión de arquitectura.

Estas fuentes acreditan capacidades documentadas, no la compatibilidad con un ERP concreto ni el rendimiento de Kiia. Para la lógica de selección completa, consulta nuestra [metodología](/es/metodologia/) y la guía sobre [Power Automate, Copilot y desarrollo a medida](/es/blog/copilot-power-automate-vs-desarrollo-medida/).

## Siguiente paso

### Valida este patrón en tu ERP y tenant.

Revisaremos el evento exacto, conector o API, permisos, política de aprobación, recorrido de excepciones y responsable operativo antes de recomendar una solución.

Revisar este flujo