---
schema_version: "1"
id: 17f0485674b7eed50d6e2321ee47d61ed0b3f2909dcfeb0baf15b88f8b3bba66
title: Optimización de licencias - Patrones
collection: architect
version: current
locale: es-mx
portal_url: https://docs.salesforce.com/architect/current/es-mx/well-architected/guides/resource-and-cost-optimization-license-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/es-mx/well-architected/guide/resource-and-cost-optimization-license-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 5aebd008407864a2153006f7ad9ecd23af6f09a02f8ac01a767200455a9ba263
products:
  - Marco bien estructurado
  - Architect Site Content Repo
---
# Optimización de licencias - Patrones

Obtenga más información acerca de la [optimización de recursos](/docs/architect/es-mx/well-architected/guide/resource-and-cost-optimization.html) y costos bien arquitectada → [Licencias y consumo](/docs/architect/es-mx/well-architected/guide/resource-and-cost-optimization.html#licensing-and-consumption)

## Tamaño correcto de licencia

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Organización | ✅ Los tipos de licencia coinciden con los requisitos de usuario reales y los patrones de uso (no los títulos de trabajo) |
| Plataforma \| Organización | ✅ Los usuarios que acceden únicamente a objetos personalizados reciben licencias de plataforma en vez de licencias completas de Salesforce |
| Plataforma \| Organización | ✅ Los usuarios externos (clientes, socios, miembros de la comunidad) utilizan licencias de Experience Cloud en vez de licencias internas |
| Plataforma \| Organización | ✅ Los usuarios que solo requieren autenticación sin acceso a datos reciben licencias de identidad |
| Plataforma \| Organización | ✅ Las auditorías de licencia trimestrales identifican usuarios que acceden únicamente a objetos personalizados como candidatos a licencia de plataforma |
| Plataforma \| Organización | ✅ Los reportes trimestrales automatizados identifican usuarios con cero inicios de sesión en 90 días, usuarios que acceden únicamente a objetos personalizados y usuarios externos con licencias internas para el dimensionamiento correcto sistemático |
| Plataforma \| Organización | ✅ Las asignaciones de licencias se revisan y se ajustan basándose en cambios de funciones en vez de permanecer sin cambios durante años |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Organización | ⚠️ Las licencias completas de Salesforce se asignan a todos los empleados basándose en el título del trabajo en vez de patrones de uso reales del sistema |
| Plataforma \| Organización | ⚠️ Los usuarios que acceden únicamente a objetos personalizados reciben licencias completas de Sales Cloud o Service Cloud en vez de licencias de Platform |
| Plataforma \| Organización | ⚠️ Los usuarios externos consumen capacidad de licencia interna en vez de licencias de Experience Cloud |
| Plataforma \| Organización | ⚠️ Las asignaciones de licencias establecidas durante la implementación inicial permanecen sin cambios durante tres años a pesar de los cambios de funciones |
| Plataforma \| Organización | ⚠️ Las auditorías de licencias nunca se realizan; el 40% de las licencias están sin utilizar o infrautilizadas |
| Plataforma \| Organización | ⚠️ Los usuarios que inician sesión menos de un mes no se identifican como candidatos para la recuperación de licencias |

## Inversión de producto complementaria

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Seguridad | ✅ Los componentes Shield (Cifrado de plataforma, Monitoreo de eventos, Seguimiento de auditoría de campo) se evalúan individualmente basándose en si abordan necesidades de cumplimiento específicas |
| Data 360 \| Arquitectura | ✅ La inversión de Data 360 está justificada por requisitos de resolución de identidad entre sistemas, acceso a datos de clientes en tiempo real o activación de segmentos |
| IA \| Negocios | ✅ La inversión de IA requiere un desempeño de la inversión demostrado en periodos de medición definidos en vez de asumir un valor no especificado |
| Plataforma \| Industry Clouds | ✅ Industry Clouds (Financial Services, Health, Manufacturing, Net Zero) se evalúan con respecto a los costos de desarrollo personalizado y los requisitos de tiempo de comercialización |
| Plataforma \| Industry Clouds | ✅ La evaluación de Industry Cloud reconoce una implementación 40-60% más rápida para flujos de trabajo estándar, pero tiene en cuenta la personalización reduciendo el ahorro de tiempo |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Seguridad | ⚠️ Todos los componentes Shield se adquieren sin evaluar si componentes específicos abordan necesidades de cumplimiento o seguridad reales |
| Data 360 \| Arquitectura | ⚠️ Data 360 se adquiere sin evaluar si enfoques de integración más sencillos cumplen los requisitos |
| IA \| Negocios | ⚠️ La inversión de IA carece de mediciones de valor de negocio mensurables o demostración de ROI |
| IA \| Negocios | ⚠️ La inversión de IA asume que el valor se entregará sin definir periodos de medición específicos o criterios de éxito |
| Plataforma \| Industry Clouds | ⚠️ Industry Cloud se adquiere sin comparar con costos de desarrollo personalizados o validar la aceleración del tiempo de comercialización |

## Gobernanza de licencia

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Aprovisionamiento | ✅ El nuevo flujo de trabajo de aprovisionamiento de usuarios asigna automáticamente licencias de plataforma para usuarios que acceden únicamente a aplicaciones personalizadas |
| Plataforma \| Aprovisionamiento | ✅ Nuevo flujo de trabajo de aprovisionamiento de usuarios coloca en cola usuarios externos para la asignación de licencias de Experience Cloud basándose en el dominio de email |
| Plataforma \| Aprovisionamiento | ✅ Las políticas de asignación definen criterios claros para tipos de licencia basándose en requisitos de uso de plataforma y función de usuario |
| Plataforma \| Aprovisionamiento | ✅ Los flujos de trabajo de aprobación requieren justificación de negocio para tipos de licencia premium |
| Plataforma \| Aprovisionamiento | ✅ La asignación de licencias apropiada se aplica en el momento del aprovisionamiento en vez de corregir asignaciones incorrectas retroactivamente |
| Plataforma \| Organización | ✅ Los procesos de recuperación identifican automáticamente usuarios inactivos (60-90 días) y reclaman licencias no utilizadas para su reasignación |
| Plataforma \| Organización | ✅ Los reportes basados en inicio de sesión identifican usuarios inactivos durante 60-90 días basándose en políticas organizativas |
| Plataforma \| Organización | ✅ La recuperación trimestral evita que se acumule el desperdicio de licencias a medida que los empleados cambian funciones o abandonan la organización |
| Plataforma \| KPI | ✅ Los tableros de monitoreo de utilización realizan un seguimiento de la frecuencia de inicio de sesión, los patrones de uso de funciones y la idoneidad del tipo de licencia |
| Plataforma \| Negocios | ✅ Los datos de utilización se comparten con líderes de negocio que activan decisiones de inversión de licencias dirigidas por datos durante la planificación de la renovación |
| **Reportes y tableros** → Tablero de utilización de licencias<br>**Configuración** → Usuarios → Usuarios activos | ✅ **Patrón**: Los tableros de utilización de licencias muestran licencias activas frente a inactivas, distribución de frecuencias de inicio de sesión, uso de funciones por tipo de licencia y distribución de tipos de licencia<br>✅ Los tableros de utilización revelan usuarios inactivos, usuarios con sobrelicencia y desajustes de tipo de licencia que requieren revisión |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Aprovisionamiento | ⚠️ Las políticas de asignación de licencias no existen; cada solicitud se gestiona ad hoc |
| Plataforma \| Aprovisionamiento | ⚠️ Los flujos de trabajo de aprobación no requieren justificación de negocio para tipos de licencia premium |
| Plataforma \| Organización | ⚠️ La identificación de usuarios inactivos es manual e infrecuente en vez de automatizada |
| Plataforma \| Organización | ⚠️ La recuperación de licencias solo se produce durante la renovación anual en vez de trimestralmente |
| Plataforma \| Organización | ⚠️ El desperdicio de licencias se acumula durante años a medida que los empleados cambian funciones o se van sin recuperación de licencias |
| Plataforma \| KPI | ⚠️ Los tableros de monitoreo de utilización no existen; los patrones de uso son desconocidos |
| Plataforma \| Negocios | ⚠️ Los líderes de negocio carecen de visibilidad sobre los datos de utilización de licencias durante la planificación de la renovación |

## Optimización de contratos

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Contratos | ✅ Los compromisos de conteo de usuarios son compatibles con planes de negocio en vez de pronósticos optimistas |
| Plataforma \| Contratos | ✅ Las programaciones de rampa hacen coincidir la inversión con la cronología de incorporación de usuarios real en vez de pagar por capacidad no utilizada por adelantado |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Contratos | ⚠️ El compromiso excesivo con los conteos de usuarios crea un desperdicio inmediato a través de licencias no utilizadas que consumen presupuesto sin entregar valor |
| Plataforma \| Contratos | ⚠️ Los acuerdos plurianuales se firman sin evaluar las necesidades de flexibilidad si las proyecciones de crecimiento resultan incorrectas |
| Plataforma \| Contratos | ⚠️ La cronología de actualización no coincide con los ciclos de planificación de negocio; los ajustes están rezagados con respecto a los cambios de conteo real |
| Plataforma \| Contratos | ⚠️ La organización lleva 200 licencias sin utilizar durante 18 meses porque el plan de contratación se retrasa después de confirmarse para alcanzar el descuento por volumen |

## Selección de edición

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Arquitectura | ✅ Planificación de arquitectura de integración proyecta el consumo de API y evalúa si Enterprise Edition o Unlimited Edition proporcionan un mejor TCO |
| Plataforma \| Arquitectura | ✅ Modelos de comparación de costos de edición por prima de usuario frente a funciones incluidas (límites de API, almacenamiento, asignaciones de sandbox, asistencia Premier) |
| Plataforma \| Arquitectura | ✅ Modelos de decisiones de edición proyectados para ambos modelos de precios con supuestos documentados que permiten una reevaluación futura |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Arquitectura | ⚠️ La selección de edición toma como valor predeterminado el nivel más alto o más bajo basándose en restricciones presupuestarias sin analizar requisitos arquitectónicos |
| Plataforma \| Arquitectura | ⚠️ Enterprise Edition está seleccionada para minimizar el costo por usuario sin proyectar requisitos de integración y costos de sobrecarga de API |
| Plataforma \| Arquitectura | ⚠️ Los requisitos de integración superan los límites después de la implementación, dando como resultado un costo 2x a través de superaciones de API más retrabajo arquitectónico |
| Plataforma \| Arquitectura | ⚠️ La decisión de edición se toma sin modelar el uso real frente a modelos de precios o documentar supuestos |
| Plataforma \| Organización | ⚠️ La selección de ediciones se basa únicamente en el costo de suscripción anual por usuario sin modelar restricciones arquitectónicas |

## Costo de licencia de múltiples organizaciones

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Arquitectura | ✅ Los enfoques de optimización de una sola organización (reglas de colaboración, conjuntos de permisos, tipos de registro) se evalúan antes de adoptar la arquitectura de múltiples organizaciones |
| Plataforma \| Arquitectura | ✅ El modelo de TCO de múltiples organizaciones muestra una multiplicación de costos operativos de 2 a 3 veces incluyendo administración, gestión de versiones, monitoreo, respuesta ante incidentes y cumplimiento |
| Plataforma \| Arquitectura | ✅ La arquitectura de múltiples organizaciones se adopta solo cuando los requisitos reguladores (residencia de datos de RGPD, separación financiera) compensan costos aumentados |
| Plataforma \| Arquitectura | ✅ La justificación de múltiples organizaciones documenta requisitos de aislamiento genuinos que una sola organización con límites de permisos no puede cumplir |
| Plataforma \| Contratos | ✅ Los costos de licencias de múltiples organizaciones modelan conjuntos de licencias separados por organización perdiendo precios por volumen y requiriendo licencias administrativas duplicadas |
| Plataforma \| Arquitectura | ✅ Los costos operativos de múltiples organizaciones modelan el mantenimiento paralelo entre múltiples implementaciones multiplicando el desarrollo y el esfuerzo operativo |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Arquitectura | ⚠️ Se adopta la arquitectura de múltiples organizaciones porque las unidades de negocio "quieren independencia" sin modelar la multiplicación de costos 2-3x |
| Plataforma \| Arquitectura | ⚠️ La adopción de múltiples organizaciones se produce sin evaluar si una única organización con reglas de colaboración cumpliría los requisitos reales a una fracción del costo |
| Plataforma \| Arquitectura | ⚠️ El modelo de TCO de múltiples organizaciones no incluye la multiplicación de costos operativos (2-3x para administrador, gestión de versiones, monitoreo, cumplimiento) |
| Plataforma \| Arquitectura | ⚠️ La arquitectura de múltiples organizaciones carece de justificación de negocio documentada que demuestre que el valor supera la multiplicación de costos permanente y compuesta |
| Plataforma \| Contratos | ⚠️ El análisis de costos de licencias de múltiples organizaciones no tiene en cuenta conjuntos de licencias separados que pierden beneficios de precios por volumen |
| Plataforma \| Arquitectura | ⚠️ La carga operativa de múltiples organizaciones no está modelada; el mantenimiento paralelo entre organizaciones se descubre después de la implementación |

## Repercusión de la licencia de integración entre organizaciones

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Integración | ✅ El TCO de múltiples organizaciones incluye licencias de MuleSoft ($20K-$200K+ anuales), desarrollo de integración, mantenimiento continuo y planificación de capacidad de API |
| Plataforma \| Integración | ✅ Los costos de integración entre organizaciones se modelan explícitamente mostrando la inversión de MuleSoft, el esfuerzo de desarrollo y los costos operativos sostenidos |
| Plataforma \| Arquitectura | ✅ La multiplicación del consumo de API está modelada: Transacciones entre organizaciones que consumen de 5 a 10 llamadas de API entre múltiples organizaciones de forma simultánea |
| Plataforma \| Integración | ✅ La sobrecarga de coherencia de datos para mantener datos de referencia sincronizados entre organizaciones incluye esfuerzo de desarrollo, monitoreo y resolución de conflictos |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| Integración | ⚠️ La arquitectura de múltiples organizaciones se aprueba basándose en la comparación de costos de licencia sin modelar costos de integración anuales de 240.000 USD |
| Plataforma \| Integración | ⚠️ Los costos de integración entre organizaciones no se modelan explícitamente; una sola organización eliminaría estos costos por completo |
| Plataforma \| Arquitectura | ⚠️ La multiplicación del consumo de API desde llamadas entre organizaciones no se tiene en cuenta en la planificación de capacidad |
| Plataforma \| Integración | ⚠️ La sobrecarga de coherencia de datos para datos de referencia sincronizados no está incluida en el modelo de TCO de múltiples organizaciones |

## Estrategia de sandbox y Gestión de recursos

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| **Configuración** → Sandboxes → Estrategia medioambiental<br>**DevOps** → Plan de asignación de sandbox | ✅ **Patrón**: El equipo utiliza sandboxes de Developer Pro para el desarrollo de funciones con datos simulados, copia parcial con cuentas dirigidas para pruebas de integración<br>✅ Reserva copia completa exclusivamente para validación de UAT de preproducción y desempeño donde el volumen de datos completo es necesario desde el punto de vista arquitectónico |
| **Configuración** → Sandboxes → Estrategia equilibrada<br>**Finanzas** → Presupuesto medioambiental | ✅ **Patrón**: El equipo de desarrollo de 15 personas implementa una estrategia equilibrada con 15 entornos sandbox Developer Pro (750 USD al mes), 3 copias parciales para transmisiones de trabajo paralelas (900 USD al mes), 1 copia completa para UAT (3.000 USD al mes)<br>✅ Totaliza 4.650 dólares mensuales coincidentes con patrones de desarrollo reales en vez de aprovisionamiento excesivo para paralelismo máximo teórico |
| **Configuración** → Plantillas de sandbox → Selección de datos<br>**Configuración** → Configuración de copia parcial | ✅ **Patrón**: La plantilla de sandbox de copia parcial incluye los últimos 12 meses de oportunidades y casos pero excluye datos archivados<br>✅ Proporciona datos de prueba representativos con una capacidad de 5 GB en vez de requerir copia completa, lo que permite el tipo de sandbox de menor costo a través de la selección de datos estratégicos |
| **Proceso** → Ciclo de vida de sandbox<br>**Configuración** → Seguimiento de entorno temporal | ✅ **Patrón**: La gestión de entornos sandbox temporales realiza un seguimiento de entornos creados para proyectos específicos con fechas de eliminación documentadas<br>✅ Implementar políticas de caducidad que requieren justificación de renovación para mantener entornos temporales más allá del ámbito inicial evitando la desviación de estado permanente |
| **Configuración** → Programación de actualización de sandbox<br>**Calendario** → Optimización de actualizaciones | ✅ **Patrón**: La optimización de la cadencia de actualización alinea la actualización de sandbox con los requisitos de actualización de datos reales en vez de programaciones arbitrarias<br>✅ Actualización de copia completa trimestral es suficiente cuando la actualización mensual es innecesaria para probar patrones, liberando capacidad para entornos sandbox adicionales |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| **Sobreaprovisionamiento** → Inversión desperdiciada | ⚠️ **Antipatrón**: La organización adquiere cinco entornos sandbox de copia completa para proporcionar a cada equipo de desarrollo entornos exclusivos<br>⚠️ Multiplica los costos de 5 a 10 veces cuando la copia parcial cumple la mayoría de los requisitos de prueba; la copia completa debe reservarse para escenarios que requieren fidelidad de producción completa |
| **Sin estrategia** → Predeterminado Premium | ⚠️ **Antipatrón**: Un equipo de 15 personas adquiere una estrategia premium con 30 Developer Pro y 5 sandboxes de copia completa (18.000 USD al mes) porque "más entornos siempre son mejores"<br>⚠️ No hay análisis que muestre la velocidad de desarrollo limitada por la disponibilidad del entorno; una estrategia equilibrada proporcionaría la misma velocidad a 4.650 dólares mensuales |
| **Plantillas sin filtrar** → Actualizaciones forzadas | ⚠️ **Antipatrón**: La plantilla Copia parcial incluye todos los objetos sin filtrar, con una capacidad de 5 GB con datos históricos irrelevantes para las pruebas<br>⚠️ Fuerza la compra de copia completa cuando la selección de datos estratégicos activa el uso de copia parcial a un costo 5-10 veces menor por sandbox |
| **Extensión de sandbox** → Temporal permanente | ⚠️ **Antipatrón**: Proliferación de entornos sandbox temporales a medida que los entornos sandbox de proyectos pasan al estado permanente sin justificación<br>⚠️ Sin políticas de caducidad o requisitos de renovación que permitan acumular entornos temporales consumiendo presupuesto indefinidamente |