Es la primera decisión arquitectónica en cualquier proyecto Power Apps: ¿dónde guardo los datos? SharePoint Lists es gratis (viene con Microsoft 365). Dataverse tiene coste adicional de licencia. La tentación es obvia — y en muchos casos, la decisión equivocada.
Los problemas reales de SharePoint como backend de apps
Empecemos por el más conocido: la delegación. Power Apps tiene un concepto llamado delegación: cuando una consulta es delegable, la fuente de datos la procesa en servidor y devuelve solo los resultados. Cuando no es delegable, Power Apps descarga registros al dispositivo y los filtra localmente — con un límite por defecto de 500 registros (configurable hasta un máximo de 2.000 en los ajustes de la app). Si tu consulta no se delega y tienes más de 500 registros, el usuario simplemente no verá todos los datos.
Con SharePoint como data source, muchas operaciones comunes no son delegables: filtros con funciones de texto como Contains, búsquedas en campos lookup, ordenaciones complejas o agregaciones. Con Dataverse, prácticamente todas las operaciones son delegables. El límite de vistas de SharePoint (5.000 elementos por vista) es otro tema — se puede trabajar con él, pero hay que tenerlo en cuenta al diseñar la app.
Pero la delegación no es el único problema, ni siquiera el principal. Los problemas más importantes de SharePoint como backend son otros: la seguridad no es a nivel de registro como en Dataverse — en SharePoint puedes poner permisos a nivel de lista o, con esfuerzo, a nivel de elemento, pero no tienes business units, security roles por tabla, ni field-level security. Las relaciones entre tablas son limitadas — los campos de tipo lookup existen, pero el modelo relacional es mucho más restringido que en Dataverse, donde tienes relaciones 1:N, N:N, y campos calculados y rollups que operan sobre esas relaciones. Y las funciones delegables dependen del data source: lo que es delegable con Dataverse no necesariamente lo es con SharePoint.
Cuándo SharePoint Lists está bien
No quiero demonizar SharePoint — tiene casos de uso legítimos para apps de Power Apps: aplicaciones con pocos cientos de registros que no van a crecer significativamente, estructuras de datos planas (sin relaciones complejas entre tablas), requisitos de seguridad básicos (todos ven todo, o seguridad por lista), y equipos que ya están familiarizados con SharePoint.
Ejemplos concretos donde SharePoint funciona bien: un registro de visitantes en recepción, un formulario de solicitud de vacaciones con aprobación simple, un inventario de equipos de oficina, o una lista de contactos de proyecto.
Cuándo necesitas Dataverse (la respuesta: antes de lo que piensas)
En cuanto aparece cualquiera de estas señales, Dataverse es la elección correcta: relaciones entre tablas (pedido → líneas de pedido → producto → proveedor), seguridad por registro o por business unit, volúmenes de datos que van a crecer más allá de unos pocos cientos de registros, lógica de negocio server-side (business rules, calculated fields, rollups), integración con otros sistemas via API, o la app va a escalar a más departamentos o entidades.
En la práctica, la mayoría de aplicaciones de negocio reales caen en esta categoría. Si la app gestiona datos que importan para el negocio — pedidos, clientes, producción, calidad, contratos — empieza con Dataverse.
El coste real de la migración: lo que nadie presupuesta
He visto este patrón varias veces: empiezan con SharePoint porque es gratis, la app funciona bien los primeros meses, los datos crecen, empiezan a aparecer problemas de rendimiento y delegación, y acaban migrando a Dataverse meses después. El coste de esa migración — rediseñar el modelo de datos, migrar registros, rehacer las referencias en apps y flujos, re-testear todo, y gestionar el periodo de transición donde ambos sistemas coexisten — suele ser significativamente mayor que si hubieran empezado con Dataverse desde el principio.
El ahorro en licencias de los primeros meses no compensa el coste de la migración y el tiempo perdido. Es una de las pocas decisiones técnicas donde ser conservador al principio sale más caro.
Marco de decisión: 4 preguntas
Cuando un cliente me pregunta, lo simplifico a 4 preguntas: ¿Los datos van a crecer más allá de unos cientos de registros? ¿Necesitas relaciones entre tablas? ¿Distintos usuarios necesitan ver distintos datos (seguridad a nivel de registro)? ¿Esta app se va a integrar con otros sistemas? Si la respuesta a cualquiera es sí, Dataverse. Si todas son no, SharePoint puede funcionar. Si no estás seguro, Dataverse — porque migrar de Dataverse a SharePoint no pasa nunca, pero al revés pasa constantemente.