Optimización de recursos y costes

La optimización de recursos y la optimización de costes funcionan conjuntamente para que su empresa alcance el máximo valor por coste. Salesforce gestiona la infraestructura de múltiples arrendatarios, aplica los límites reguladores que mantienen la plataforma justa para cada arrendatario y fija los precios del acceso a través de licencias y créditos de consumo. Lo que optimiza es el valor que obtiene de vuelta: cuánto resultado comercial devuelve cada dólar de gasto y cada unidad de capacidad de plataforma. La optimización de recursos es el mecanismo: Hace un uso eficiente de lo que ya paga. La optimización de costes es el resultado: dirige el gasto deliberadamente hacia lo que impulsa la ventaja competitiva. Este pilar los trata como una decisión porque son dos vistas del mismo objetivo.

Esta vista de valor por coste da forma a cada decisión arquitectónica que toma. Cuando comprende el coste total de propiedad, obtiene mejores ventajas entre capacidad e inversión. Asigne el tamaño correcto a las soluciones para que coincidan con los requisitos comerciales en vez de sobreaprovisionar funciones que no se utilizan o que no invierten lo suficiente en funciones que aceleran la entrega de valor. Una licencia, un crédito de consumo, una llamada de API y un entorno de sandbox son entradas a la misma ecuación. Lo que importa es el valor que devuelve cada uno, no en qué libro mayor se encuentra. La pregunta nunca es "¿es esto un coste o un recurso", pero "tiene esta entrada una devolución apropiada?"

Olvidar este pilar produce consecuencias predecibles. Las empresas acumulan licencias no utilizadas que consumen presupuesto mientras que otras funciones permanecen sin financiación. Las arquitecturas ineficientes desperdician capacidad de API, almacenamiento y esfuerzo de desarrollo en problemas que un mejor diseño evita. Ineficiencia de recursos en compuestos concretos a lo largo del tiempo de formas predecibles:

El rendimiento se degrada a medida que crecen los volúmenes de datos.
Los tiempos de espera de consultas emergen en algunos cientos de miles de registros cuando las consultas no selectivas exploran tablas completas.
Las excepciones de límite de pila aparecen cuando las soluciones recuperan campos innecesarios.
Los tiempos de espera de CPU afloran cuando los cálculos complejos se ejecutan de forma síncrona.
Las soluciones se multiplican a medida que los equipos cambian cada nuevo límite.

Cada uno de estos fallos es un problema de fiabilidad y un problema de coste, ya que el cálculo desperdiciado consume la capacidad que paga. Lo que es más importante, los equipos pierden oportunidades de invertir en innovación porque el presupuesto y la capacidad de ingeniería se consumen por desechos en vez de por iniciativas estratégicas.

Las soluciones rentables maximizan el valor:

Uso de funciones de plataforma que ya están adquiridas
Alinear la licencia y el consumo del tamaño correcto con el uso real
Modelado del coste completo antes de comprometerse con un enfoque
Supervisión del gasto de forma continua en función de los resultados comerciales

Estas prácticas son complejas. Los equipos que crean conciencia de costes y eficiencia de recursos en su diseño entregan más funciones por dólar que los equipos que tratan la optimización como un ejercicio de limpieza después de que el gasto ya haya crecido.

Optimización de recursos y costes se conecta a otros pilares arquitectónicos directamente. Operational Excellence reduce los costes continuos con una automatización que reduce el esfuerzo manual. La fiabilidad y Fiabilidad justifican las inversiones en primas a través de la garantía de continuidad comercial y el valor de cumplimiento normativo. Juntos, estos pilares ayudan a las empresas a invertir con confianza porque su arquitectura ofrece el máximo retorno.

Utilice estos principios para guiar sus decisiones de arquitectura para la optimización de recursos y costes en la plataforma.

Optimice el coste total de propiedad. El coste total de propiedad (TCO) se extiende más allá de las comisiones de suscripción a créditos de consumo, costes de implementación, costes operativos, gastos de integración y esfuerzo de gestión de cambios. Evalúe decisiones utilizando análisis de TCO para revelar la imagen completa de la inversión durante la vida útil de una solución. A veces, una mayor inversión inicial reduce sustancialmente los costes operativos en curso, y el análisis de TCO aflora esa compensación. Optimizar para valor a largo plazo, no minimizar costes a corto plazo.
Alinee el gasto con el valor comercial. Conecte cada inversión de Salesforce con un resultado comercial mensurable. El gasto de licencia permite la productividad del usuario medida a través de la adopción y la realización de tareas. La inversión de Data 360 potencia la toma de decisiones medida a través de la conversión y el valor de vida útil del cliente. Los costes de sandbox financian la velocidad de desarrollo medida a través de la frecuencia y la calidad de la implementación. Cuando el gasto se alinea con el valor, invierte con confianza en lo que impulsa el éxito e identifica el gasto que ya no obtiene su retorno.
Diseño dentro de los límites de plataforma. Los límites reguladores definen lo que una solución puede procesar por transacción. Trátelos como restricciones de diseño desde el principio, no como obstáculos para solucionar. Diseñe transacciones que funcionen cómodamente dentro de límites bajo carga máxima y volúmenes de datos máximos, y cree margen para funciones futuras, otros paquetes instalados y patrones de datos inesperados. Las soluciones diseñadas dentro de los límites desde la concepción tienen un rendimiento predecible y evitan la refactorización de emergencia más adelante.
Optimice los recursos que ya paga. Antes de comprar más capacidad, maximice el rendimiento, la eficiencia y el valor de los activos de plataforma ya aprovisionados. Consultas eficientes, procesamiento de registros de forma masiva (masificación), almacenamiento en caché y ciclo de vida de datos disciplinado reducen el consumo de computación, almacenamiento y API que necesita una solución. Esta eficiencia de recursos es el mecanismo que impulsa la optimización de costes sostenible: Los residuos eliminados de los recursos aprovisionados mejoran tanto el rendimiento como el TCO a largo plazo.
Licencias de tamaño correcto y consumo para uso real. Compare cada usuario con el tipo de licencia que requiere su trabajo y diseñe automatizaciones y agentes para invocar servicios medidos de forma eficiente. La concesión de licencias excesivas y los créditos al consumo no supervisados son algunas de las fuentes más comunes y costosas de desechos. Las auditorías regulares de funciones, actividad de inicio de sesión y uso de funciones afloran oportunidades de enderezamiento, y una visibilidad clara de la quema de crédito mantiene los costes basados en el consumo predecibles.
Establecer una gobernanza financiera y una cultura de costes. Gestione el gasto de Salesforce como una inversión estratégica a través de supervisión activa y rendición de cuentas compartida. La gobernanza financiera aporta el análisis de coste-beneficio en las decisiones de diseño en vez de descubrir costes tras la implementación. La conciencia de costes es una responsabilidad compartida entre partes interesadas comerciales, arquitectos y desarrolladores que ponderan las implicaciones de costes junto con los requisitos funcionales, de modo que las decisiones de inversión inteligentes se producen en todos los niveles sin cuellos de botella centralizados.
Practicar la optimización continua. La optimización es una práctica continua, no un ejercicio puntual. Supervise el gasto y el consumo de recursos a través de paneles accesibles para partes interesadas técnicas y comerciales. Configure alertas que se activan cuando el gasto de consumo alcanza umbrales antes de que el consumo desbocado pase desapercibido. Las revisiones periódicas descubren desechos que se acumulan gradualmente, validan que las inversiones de optimización anteriores entregaron su retorno esperado y afloran nuevas oportunidades a medida que evolucionan las prioridades comerciales y los volúmenes de datos.

Comprender qué opera Salesforce le ayuda a centrar el esfuerzo de optimización en lo que controla. La plataforma gestiona la gestión de recursos a nivel de infraestructura que requiere equipos exclusivos en entornos de TI tradicionales:

Asignación de recursos de múltiples: Salesforce garantiza un uso compartido justo de CPU, memoria y conexión de base de datos entre todos los clientes en infraestructura compartida, supervisa el consumo de arrendatarios y aplica límites que evitan que cualquier arrendatario único degrade el rendimiento para otros.
Arquitectura de límite regulador: Los límites impuestos por plataforma (100 consultas SOQL por transacción síncrona, 10 segundos de tiempo de CPU, 6 MB de tamaño de pila) protegen a todos los arrendatarios del agotamiento de recursos. Salesforce calibra estos límites para la capacidad de infraestructura de múltiples arrendatarios. Estos límites son límites arquitectónicos, no restricciones arbitrarias.
Optimizador de consultas y motor de ejecución: El optimizador de consultas de Salesforce genera planes de ejecución, mantiene estadísticas sobre la distribución de datos y selecciona rutas de consulta óptimas. Los índices gestionados por plataforma en campos estándar aceleran patrones de consulta comunes y el optimizador se adapta a cambios de volumen de datos automáticamente.
Escala de infraestructura: Salesforce aprovisiona capacidad de hardware, gestiona clústeres de bases de datos, distribuye la carga y amplía la infraestructura a medida que crece el uso. Nunca aprovisiona servidores, gestiona la replicación de bases de datos o configura equilibradores de carga.
Optimización del rendimiento de plataforma: Salesforce optimiza continuamente el código de plataforma principal, la ejecución de consultas, los tiempos de respuesta de API y el rendimiento del marco de trabajo de la interfaz de usuario, y entrega mejoras de infraestructura a través de sus versiones regulares sin requerir acción del cliente.

Salesforce también gestiona el lado comercial de la plataforma, por lo que las licencias y el consumo pertenecen al mismo pilar que la informática y el almacenamiento. La plataforma define las ediciones, los tipos de licencia, los complementos y los modelos de crédito de consumo a través de los que se compra capacidad, y mide el uso que reduce esos créditos. No establece esos precios más que aprovisionar los servidores, pero decide cuánto de cada uno consume: qué licencia tiene cada usuario, con qué eficiencia invoca una automatización un servicio medido, cuántos entornos sandbox permanecen activos.

Estas operaciones de plataforma son la base sobre la que construye. Como Salesforce gestiona la infraestructura y el modelo de precios, su esfuerzo de optimización se centra completamente en las decisiones arquitectónicas que toma sobre ellos: con qué eficiencia utiliza los recursos que se le aprovisionan y con qué deliberadamente dirige el gasto que los aprovisiona.

El modelo de responsabilidad compartida significa que posee eficiencia de recursos para todo lo que crea dentro de Salesforce. La gestión de recursos de plataforma admite su trabajo, pero no sustituye su necesidad de optimizar. Una solución eficiente devuelve más valor comercial desde la capacidad de computación, almacenamiento y API que ya paga, y ese es el mecanismo que mantiene la optimización de costes sostenible en vez de un recorte de presupuesto puntual. El cálculo derrochador, por el contrario, consume recursos de infraestructura sin entregar valor comercial y sus compuestos de costes. El rendimiento se degrada de forma predecible a medida que crecen los volúmenes de datos, y las soluciones se multiplican a medida que los equipos cambian los límites que podrían haber diseñado.

Sus responsabilidades de optimización abarcan cuatro áreas interconectadas: rendimiento, organización de código, empaquetado y datos. Cada una es una decisión de valor por coste antes de ser técnica. Esta sección explica cómo tomar esa decisión y por qué es importante. Las recetas de implementación exactas, las plantillas a nivel de código, la navegación de configuración y los umbrales de ajuste específicos a los que se hace referencia en esta sección están en la biblioteca de patrones Optimización de recursos y costes.

La optimización del rendimiento comienza con un cambio en cómo considera los límites reguladores. No son obstáculos para trabajar. Son restricciones arquitectónicas que, cuando se adoptan desde el diseño inicial, producen soluciones con características de rendimiento predecibles. Cada transacción se ejecuta dentro de límites fijos, y esos límites existen para aplicar una colaboración de recursos justa entre cada arrendatario en la plataforma. Una transacción Apex consumiendo 95 de sus 100 consultas SOQL permitidas no deja margen para futuras funciones, desencadenadores agregados por otros equipos o patrones de datos inesperados. Los arquitectos que mantienen las transacciones muy por debajo de la mitad del límite crean soluciones que pueden crecer sin refactorización de emergencia cuando se agota un límite. La disciplina es diseñar bien dentro de los límites bajo carga máxima y en volúmenes de datos máximos, de modo que agregar una función u otra automatización de paquete nunca empuja una transacción al límite. Un fallo común y costoso: la solución funciona perfectamente contra 10 registros en un Developer Sandbox, pero alcanza los límites reguladores en producción. Los entornos sandbox de desarrollador solo copian la configuración y no contienen datos. Las pruebas con volúmenes realistas en un entorno sandbox de copia completa afloran problemas de escalabilidad antes que los clientes.

La selectividad de consultas es la palanca más grande sobre si una solución se amplía a millones de registros o agota el tiempo de espera en cientos de miles. Las consultas selectivas utilizan índices para localizar registros de forma eficiente, mientras que las consultas no selectivas exploran tablas completas, consumen recursos de base de datos excesivos y, finalmente, agotan el tiempo de espera. La plataforma mantiene índices estándar en un conjunto definido de campos y aplica umbrales de selectividad que se endurecen a medida que un objeto crece más allá de su primer millón de registros. La arquitectura para selectividad significa filtrar en campos indexados como su criterio principal y validar con la Herramienta Plan de consulta antes de implementar con objetos de gran tamaño, porque una consulta que muestra un escaneo de tabla en un objeto de gran volumen es un incidente de producción que está a la espera de producirse. Selectividad es la capacidad que no tiene que comprar: una consulta eficiente devuelve en milisegundos y deja recursos de base de datos disponibles para cada otro arrendatario y cada otra transacción en su propia organización.

La masificación es el patrón de escalabilidad fundamental que distingue Apex que funciona a escala de Apex que alcanza límites. El antipatrón (una consulta o una declaración DML colocada dentro de un bucle) funciona correctamente con conjuntos de registros pequeños pero infringe los límites reguladores en el momento en que se ejecuta una operación masiva. El remedio es consultar todos los datos necesarios en declaraciones únicas fuera de bucles, organizar los resultados en mapas con Id. para una búsqueda rápida durante la iteración y procesar una recopilación completa con DML por lotes. Diseñe cada automatización para gestionar el lote de desencadenadores estándar de 200 registros sin acercarse a límites, y las mismas escalas de código sin importar la carga en producción.

El procesamiento asíncrono existe para el trabajo que no se puede o no se debe completar dentro de los límites síncronos de una transacción de usuario. Mover ese trabajo a un contexto asíncrono duplica aproximadamente los límites reguladores disponibles y evita que las operaciones de larga ejecución bloqueen usuarios. Ese margen de maniobra es real, pero no es libre, y alcanzar la sincronización siempre que un límite se siente cerca es un error. Asíncrono es una compensación arquitectónica deliberada: introduce coherencia eventual, de modo que el resultado del trabajo no es visible en la transacción que lo solicitó, lo que obliga a tomar decisiones de experiencia de usuario que no dependen de la confirmación instantánea. Requiere gestión y supervisión explícita de errores, ya que un fallo aparece en un registro de trabajo en vez de en el usuario que lo desencadenó. Además, puede complicar el modelo mental del sistema cuando una única operación comercial abarca varias transacciones. La decisión de relación calidad-precio es ponderar esa complejidad agregada con la capacidad que necesita realmente el trabajo y mantener el trabajo sincronizado cuando se ajusta cómodamente.

Cuando asíncrono es la llamada correcta, la elección entre los mecanismos sigue la forma del trabajo en vez del tamaño del límite. Lote Apex es para volumen. Procesa millones de registros dividiéndolos en fragmentos, cada uno con sus propios límites reguladores independientes, por lo que la migración de datos, el archivado de datos y el enriquecimiento masivo pertenecen aquí. En cola es para secuencia: gestiona flujos de trabajo de múltiples pasos que superan los límites síncronos pero no necesitan escala por lotes, y admite encadenar un trabajo de otro para pasos que deben ejecutarse en orden. Eventos de plataforma son para desvincular: un productor emite un evento sin conocer o esperar a sus consumidores. Utilice este patrón para la notificación entre sistemas y para separar el trabajo que no pertenece a la misma transacción, teniendo en cuenta que la entrega al menos una vez requiere suscriptores idempotentes. Los métodos futuros cubren el caso restringido de trabajo asíncrono simple con entradas primitivas, más comúnmente una llamada desde un desencadenador síncrono. Su incapacidad para encadenar o aceptar objetos complejos es precisamente la razón por la que no son una herramienta para el trabajo asíncrono de uso general. Haga coincidir el mecanismo asíncrono con la forma del trabajo. De lo contrario, cambia un problema de límite regulador por coherencia y costes de supervisión que superan la ganancia.

El almacenamiento en caché convierte el trabajo repetido en capacidad que mantiene. Caché de plataforma almacena datos serializables entre límites de transacciones, de modo que una coincidencia de caché evita volver a ejecutar la consulta o el nuevo cálculo que produjo el valor, reduciendo directamente el consumo de SOQL y CPU. La decisión que toma o rompe una caché es lo que elige poner en ella y durante cuánto tiempo. Almacena en caché datos que se leen con mucha más frecuencia de lo que cambian, como metadatos personalizados, configuración y valores de lista de selección, y establece el tiempo de vida útil para coincidir con la volatilidad de los datos en vez de con un único valor predeterminado. Los datos de referencia que cambian mensualmente pueden almacenarse en caché de forma segura durante horas, mientras que la configuración que cambia a lo largo del día necesita un plazo corto de modo que la memoria caché nunca sirve un valor obsoleto lo suficientemente largo como para importar. Una caché que es demasiado agresiva intercambia una ganancia de rendimiento por un riesgo de corrección, y una caché con un índice de aciertos deficiente gasta almacenamiento sin devolver capacidad, por lo que el índice de aciertos es una medición a supervisar en vez de un parámetro a asumir. La opción de partición es una decisión de seguridad: Utilice la partición de organización para datos compartidos entre usuarios, utilice la partición de sesión para datos con ámbito de usuario que deben permanecer aislados y nunca coloque información de identificación personal en la partición de organización donde cada usuario pueda leerla. Lightning Data Service amplía la misma idea al cliente: comparte registros en caché entre cada componente de una página y elimina los recorridos de ida y vuelta redundantes del servidor. Cada acierto de caché es computación y capacidad de API que no tiene que gastar, siempre que el valor que devuelve siga siendo correcto.

El sesgo de datos es un punto de acceso de rendimiento creado por una distribución de registros desequilibrada. Cuando un único registro principal acumula más de 10.000 registros secundarios, el rendimiento de la consulta se degrada y la contención de bloqueo de filas emerge durante operaciones simultáneas. El umbral es una señal de diseño, no un límite fijo. Le indica distribuir la carga entre múltiples principales, supervisar objetos de gran volumen con trabajos programados que alertan cuando cualquier principal se acerca al límite y ordenar cargas masivas por Id. principal de modo que los lotes simultáneos no se peleen en las mismas filas. El sesgo de propiedad, donde un usuario de integración posee cientos de miles de registros, produce la misma contención de bloqueo y merece la misma distribución de carga.

Salesforce proporciona herramientas para mantener las características de rendimiento saludables a medida que evoluciona una solución. Scale Center proporciona visibilidad a nivel de transacción de operaciones de larga ejecución, contención de bloqueo de filas y transacciones que se acercan a límites, luego nombra el desencadenador específico y el objeto implicado. ApexGuru aplica el análisis de IA a la telemetría en tiempo de ejecución de producción para aflorar antipatrones antes de que alcancen la escala, y Salesforce Code Analyzer realiza análisis estáticos en las oportunidades en curso de CI/CD de modo que las compilaciones fallan cuando aparecen consultas dentro de bucles u otros defectos de rendimiento detectados. Event Monitoring revela tendencias de consumo a lo largo del tiempo, y Proactive Monitoring, una función de plan de éxito de Signature, evalúa continuamente la organización en busca de riesgos de rendimiento y escalabilidad.

La organización de código es una decisión de coste expresada como capacidad de mantenimiento. El mantenimiento suele consumir la mayor parte de la capacidad de desarrollo para una solución madura, de modo que la estructura que elija determina cuánta capacidad futura cambiará en vez de reelaborar. Tres patrones llevan la mayor parte de ese valor. El patrón del gestor de desencadenadores centraliza la lógica de desencadenadores en clases de gestor y reduce el archivo de desencadenador en sí a un punto de delegación mínimo, lo que mantiene la lógica comprobable independientemente del contexto del desencadenador y proporciona al control de recursión un único inicio. El patrón de capa de servicio encapsula la lógica comercial en clases que exponen operaciones invocables desde un desencadenador, un extremo de REST, un invocable de flujo o un trabajo por lotes, de modo que una regla comercial vive en una implementación en vez de duplicarse en cada punto de entrada y quedar fuera de sincronización. El patrón de selector centraliza SOQL para cada objeto en clases dedicadas, lo que hace que el ajuste de consultas sea un cambio de un solo punto y proporciona a cada consulta una intención explícita nombrada.

Los errores DML mixtos son un riesgo organizativo distinto contra el que vale la pena diseñar explícitamente. Se producen cuando una transacción realiza DML en objetos de configuración, como Usuario y Conjunto de permisos, y objetos que no son de configuración, como Cuenta y objetos personalizados, porque los cambios de configuración que afectan al acceso de un usuario deben confirmarse en una transacción separada. El fallo aflora a escala en trabajos de integración, en la configuración de pruebas y en la automatización de aprovisionamiento de usuarios. Los remedios arquitectónicos son separar DML de configuración y no de configuración entre límites de transacciones utilizando procesamiento asíncrono o Eventos de plataforma, diseñar modelos de datos que eviten combinar las dos operaciones en un único paso comercial y aislar DML de configuración en pruebas.

Las opciones de empaquetado configuran el coste de desarrollo a largo plazo y la reutilización que puede lograr en una empresa. Los paquetes gestionados de segunda generación proporcionan desarrollo modular dirigido por origen con protección de espacio de nombres y son la opción correcta para productos de proveedor de software independiente (ISV) distribuidos a través de AgentExchange. Los paquetes desbloqueados proporcionan a los equipos internos la misma modularidad y gestión de dependencias sin sobrecarga de espacio de nombres, lo que se adapta a aplicaciones empresariales que necesitan implementación independiente pero sin listado de mercado. Los paquetes gestionados de primera generación permanecen en uso para productos existentes pero carecen del flujo de trabajo dirigido por el origen que hace que el nuevo desarrollo modular sea mantenible.

La modularidad se extiende a los componentes que crea. Diseñe componentes web Lightning alrededor de una única responsabilidad con interfaces de propiedades claras, favorezca la composición sobre la herencia de modo que las interfaces de usuario complejas se reúnan a partir de pequeños componentes centrados y utilice eventos personalizados para la comunicación principal en vez de llegar directamente a un principal. Exponga Apex reutilizable como acciones invocables de modo que los administradores puedan redactar la automatización en Flow Builder desde funciones creadas por el desarrollador, lo que reduce la duplicación y acorta el mundo declarativo y programático. La modularidad bien diseñada es lo que permite crear una capacidad una vez y reutilizarla, en vez de reimplementarla y mantenerla por separado en cualquier lugar que sea necesario.

El crecimiento de datos no gestionados es la fuente más común de degradación gradual del rendimiento, y dirige el coste de almacenamiento y el tiempo de actualización de sandbox en paralelo. Dos decisiones rigen la eficiencia de los datos. El primero es el diseño del modelo de datos. Las relaciones principal-detalle proporcionan eliminación en cascada, resúmenes y colaboración de datos al coste de un acoplamiento más estrecho. Las búsquedas proporcionan flexibilidad al coste de la lógica de acumulación personalizada, y una estrategia de índice deliberada en los campos que filtra mantiene las consultas selectivas a medida que crecen los objetos. El segundo es el ciclo de vida de los datos. Defina un ciclo de vida completo desde la creación a través del archivado en vez de permitir que los objetos acumulen registros indefinidamente, ya que un objeto que crece en millones sin una estrategia de archivado produce eventualmente tiempos de espera de consultas, consultas no selectivas y vistas de lista que agotan el tiempo de espera.

Seleccione el mecanismo de archivado solo después de liquidar el cumplimiento. Antes de seleccionar un mecanismo, confirme si los requisitos de residencia de datos, derecho de eliminación o retención restringen sus opciones. Los Big Objects no se pueden modificar después de insertar, lo que hace que la eliminación solo de registros de datos personales archivados sea una operación de eliminación y recreación que puede afectar a los seguimientos de auditoría. Big Objects almacena conjuntos de datos históricos masivos en almacenamiento separados de los límites estándar y se adaptan a transacciones completadas y registros de auditoría que ya no son necesarios para el trabajo diario. El almacenamiento externo mantiene los datos consultables a través de Salesforce Connect mientras reduce el volumen de la organización y se adapta a patrones de consulta flexibles o integración con un almacén de datos de empresa. Supervise el consumo de almacenamiento a nivel de objeto de modo que el crecimiento sea visible antes de que se convierta en un problema, utilice Salesforce Files en vez de Archivos adjuntos heredados y configure la retención de Seguimiento de auditoría de campo por campo para lo que requiere el cumplimiento, en vez de aplicar un máximo general que desperdicia almacenamiento.

La optimización de costes equilibra el valor comercial con el coste de la solución, y depende de establecer un coste preciso en primer lugar. Para ello, tenga en cuenta cada componente de coste, ya que mirar un único componente, como el coste de licencia, lleva a una comprensión incorrecta de lo que cuesta realmente la solución. Una tarifa de licencia modesta puede ocultar costes de implementación, operativos, integración y cambio que la eclipsan. Una decisión tomada sobre el número visible solo utiliza parte de la imagen. Coste total de propiedad es el modelo que captura la imagen completa. Abarca todos los costes asociados con una solución de Salesforce a lo largo de su vida útil y los separa en costes directos, que están claramente asociados con la solución, y costes indirectos, que son reales pero fáciles de pasar por alto. El modelado convierte una estimación de coste en una decisión de arquitectura fundamentada que pondera el valor a largo plazo en vez de solo el gasto inicial.

Los costes directos se generan por la implementación, operación y mantenimiento del sistema:

Los costes de licencia y consumo son comisiones de suscripción continuas que varían por edición, tipo de usuario y conjunto de funciones, además de créditos basados en consumo. La opción de edición es una decisión de coste fundamental porque las diferencias por usuario son significativas. Los costes de consumo son difíciles de modelar de forma temprana, de modo que vuelva a visitar esas estimaciones a medida que se toman decisiones de diseño.
Los costes de implementación cubren el diseño, el desarrollo, las pruebas, la migración de datos y la formación de las soluciones. Son predominantemente puntuales pero crean obligaciones de mantenimiento continuas proporcionales a la complejidad. Las empresas subestiman sistemáticamente el esfuerzo de implementación porque se centran en el desarrollo e infravaloran las pruebas y la formación.
Los costes operativos cubren la administración, la asistencia al usuario, la supervisión, la respuesta ante incidentes y las herramientas operativas. Crecen con la complejidad de las soluciones y a menudo son invisibles en la planificación porque se manifiestan como esfuerzo interno en vez de facturas externas.
Los costes de mantenimiento cubren la mejora, la solución técnica de deudas, la adaptación de versiones y los cambios de configuración. El mantenimiento suele consumir del 60 al 80% de la capacidad de desarrollo de soluciones maduras, lo que lo convierte en la categoría de costes continua más grande.
Los costes de integración incluyen licencias de plataforma de integración, consumo de API, desarrollo de sincronización y mantenimiento continuo. Crecen con la complejidad de los ecosistemas porque la integración de punto a punto compone el mantenimiento a medida que aumenta el recuento del sistema.
Los costes de cambio cubren el rediseño de procesos comerciales, la gestión de cambios, la adopción y la coordinación de partes interesadas. Aumentan con el alcance entre unidades comerciales y regiones, y se omiten con frecuencia porque se manifiestan como esfuerzo de equipo comercial.

Los costes indirectos no son visibles inmediatamente en la planificación inicial pero se acumulan significativamente a lo largo de la vida útil de una solución, y para implementaciones maduras a menudo superan los costes directos. Una empresa que optimiza solo sus costes directos mientras ignora el gasto indirecto pierde la mayoría de su inversión total. Varias categorías merecen atención explícita.

Los costes organizativos son las inversiones que impulsan el éxito de Salesforce pero nunca aparecen en una factura de Salesforce. Incluyen salarios de equipos internos para administradores, desarrolladores y arquitectos, infraestructura de desarrollo como control de versiones y herramientas de CI/CD, mantenimiento de formación y certificación y desarrollo de habilidades, y el coste de oportunidad de la capacidad de desarrollo asignada al mantenimiento en vez de a la innovación. Ese último elemento es difícil de detectar, porque no se muestra como gastado en absoluto. Se muestra como la innovación que nunca se envió.

Los intereses de deuda técnica son el coste compuesto de los accesos directos arquitectónicos. Los accesos directos realizados para cumplir un plazo de lanzamiento crean una carga de mantenimiento que puede requerir varias veces el esfuerzo original para resolverse más adelante, y cada sprint empleado en remediar la deuda es un sprint que no entrega nuevo valor comercial. Los equipos que aplazan las mejoras de arquitectura el tiempo suficiente encuentran que la mayor parte de su capacidad se destina al mantenimiento en vez de a nuevas funciones.

Los gastos generales de gobernanza consumen tiempo a través de procesos de aprobación, reuniones de coordinación y revisiones manuales. La gobernanza ofrece un valor real a través de la reducción del riesgo y la coherencia, pero una gobernanza excesiva crea costes ocultos a través de decisiones demoradas y esfuerzos duplicados, por lo que el objetivo es diseñar sistemas que promuevan la autonomía segura en vez de requerir un cuello de botella de aprobación centralizado para cada cambio.

Las funciones no utilizadas se acumulan cuando se implementan funciones pero nunca se adoptan completamente. Una solución implementada parcialmente consume mantenimiento continuo sin entregar valor proporcional, y la utilización de licencias y la supervisión de la adopción de funciones revelan capacidades para invertir más o retirarse para redirigir la capacidad.

La visibilidad integral de costes requiere atribuir partidas directas y estas indirectas, ya que solo la imagen completa admite una decisión de inversión correcta.

Cree modelos de TCO para su línea base y para alternativas de arquitectura optimizadas antes de comprometerse con un enfoque. Los modelos que proyectan costes de 3 a 5 años con suposiciones documentadas le permiten comparar opciones de forma sistemática. Ejecute análisis de sensibilidad en los supuestos que más importan para determinar las variaciones y los límites de las estimaciones de costes. Planifique volver a tomar decisiones a medida que cambien las condiciones. La disciplina de escribir las suposiciones es parte del valor, porque hace que una reevaluación posterior sea una comparación basada en evidencia en vez de un argumento nuevo.

Evalúe las soluciones disponibles comercialmente frente al desarrollo personalizado utilizando una comparación de TCO integral en vez del coste inicial únicamente. Las decisiones de construcción frente a compra configuran la inversión a largo plazo a través de comisiones de suscripción continuas u obligaciones de mantenimiento continuas, y las dos rutas llevan perfiles de inversión fundamentalmente diferentes.

AgentExchange (anteriormente conocido como AppExchange) es el origen líder de soluciones preparadas de la comunidad de ISV de Salesforce. Su perfil de inversión favorece la velocidad y el mantenimiento compartido. La implementación se mide en semanas en vez de los meses que requiere una compilación personalizada comparable. El proveedor mantiene la funcionalidad, incluyendo la compatibilidad de versión de plataforma, sin el esfuerzo del cliente. La funcionalidad está probada por una base de clientes existente, lo que reduce el riesgo de implementación. Las funciones especializadas se benefician de la experiencia en el dominio de proveedores y la inversión en investigación que supera lo que una única empresa financiaría por sí misma. La disponibilidad de asistencia varía por ISV, normalmente con una ruta de distribución definida para problemas, y conlleva un coste de suscripción continuo para el modelo.

El desarrollo personalizado favorece el ajuste y el control. Se alinea con precisión con requisitos organizativos exclusivos sin comprometer patrones de soluciones genéricas, proporciona control completo sobre las prioridades de funciones y hojas de ruta, no lleva ninguna suscripción continua más allá de licencias de plataforma base y puede crear ventajas competitivas a través de funciones no disponibles para competidores que utilizan las mismas soluciones estándar. La desventaja es que la empresa asume la responsabilidad completa del mantenimiento y de mantener la solución compatible con cada versión de Salesforce.

Una comparación de TCO a largo plazo convierte esos perfiles en una decisión. Las soluciones preparadas conllevan comisiones de suscripción anuales compuestas pero incluyen actualizaciones de mantenimiento, mejora y compatibilidad proporcionadas por el proveedor. Las soluciones personalizadas requieren una inversión de desarrollo puntual pero conllevan costes de mantenimiento continuos además de la responsabilidad completa de la compatibilidad de versiones. Proyecto de 3 a 5 años totales para ambos de modo que la comparación refleja la inversión completa en vez del gasto inicial, que suele favorecer cualquier opción que pareciera más barata en el primer día.

Más allá del coste bruto, cuatro factores dan forma a la decisión de construcción frente a compra.

La diferenciación estratégica determina si una capacidad es una ventaja competitiva que vale la pena crear o un producto mejor adquirido.
El tiempo para valorar favorece la compra cuando se necesita una función de inmediato para capturar una oportunidad o responder a la presión de la competencia, porque las funciones personalizadas sustanciales tardan meses.
La capacidad organizativa favorece la creación solo donde existe un equipo interno capaz con la capacidad de mantener y evolucionar la solución a lo largo del tiempo, y favorece la compra cuando esa capacidad está ausente.
El coste de salida favorece opciones que mantienen la flexibilidad, ya que una solución que crea un bloqueo profundo a través de formatos propios o personalización amplia es un riesgo si cambian los requisitos.

Sistematice la decisión de modo que se base en una evaluación coherente en vez de un juicio ad hoc.

Las licencias y el consumo son entradas a la ecuación de valor por coste del mismo modo que la computación y el almacenamiento, y se encuentran entre las fuentes más comunes de desechos. Optimizarlas no se trata de reducciones contundentes. Se trata de hacer coincidir cada usuario con la licencia correcta para su trabajo e invocar cada servicio medido de forma eficiente.

La optimización de licencias hace coincidir cada usuario con el tipo de licencia correcto. En esencia, se trata de hacer coincidir cada usuario de la empresa con la licencia que requiere su trabajo. La sobrelicencia, como la asignación de licencias de plataforma completas a usuarios que solo necesitan funciones limitadas (acceso de solo lectura o aprobaciones de flujos de trabajo sencillas), es uno de los errores más comunes y costosos que cometen las empresas, y es invisible hasta que alguien mira. Una auditoría regular de funciones de usuario, actividad de inicio de sesión y uso de funciones aflora ahorros significativos al ajustar el tamaño de las asignaciones en la base de usuarios. Ejecútelo en una cadencia, no solo en la renovación: los desajustes crecen silenciosamente a medida que cambian las funciones y las personas cambian posiciones en la empresa.

La optimización del crédito de consumo importa cada vez más a medida que las empresas adoptan Agentforce, Data 360 y otras funciones con tecnología de IA que fijan el precio por uso en vez de por asiento. Los grupos de créditos pueden agotarse sorprendentemente rápido cuando los equipos diseñan sus procesos de forma ineficiente o no supervisan sus patrones de uso. A diferencia de un recuento de licencias fijo, el consumo puede aumentar sin que se tome ninguna decisión de aprovisionamiento. Establezca una visibilidad clara de los índices de quema de crédito, establezca umbrales de consumo que desencadenan la revisión y diseñe automatizaciones y agentes para ser eficientes en el modo en que invocan servicios medidos. El mismo trabajo de eficiencia que mantiene una transacción dentro de los límites reguladores mantiene un servicio medido dentro de su presupuesto de crédito. Es la misma idea de valor por coste, expresada en términos de consumo.

La estrategia de entorno y sandbox es una decisión de recurso con consecuencias de coste directo, y un modelo de entrega maduro de Salesforce requiere una estrategia de entorno bien estructurada. Los entornos de desarrollo, prueba, organización y producción sirven a un propósito distinto, y la combinación correcta de tipos de sandbox permite a los equipos crear y validar cambios de forma segura antes de que lleguen a producción. El reto es que sin una gobernanza deliberada, el número de entornos sandbox activos prolifera rápidamente, especialmente en programas de larga o larga ejecución, y eleva el coste de formas que pillan a las empresas con la guardia baja. El remedio es tratar el aprovisionamiento de entornos sandbox con la misma intencionalidad que cualquier otro recurso. Actualice o anule el aprovisionamiento de entornos sandbox que ya no están en uso activo en vez de dejarlos inactivos, permita que la elección del tipo de entorno sandbox esté dirigida por la necesidad de fidelidad de datos real en vez de la comodidad, y establezca políticas claras para la propiedad, la cadencia de actualización y el desmantelamiento de modo que el estado permanezca dimensionado al trabajo.

La arquitectura de múltiples organizaciones multiplica el coste. Una arquitectura de organización única se beneficia de licencias consolidadas, infraestructura de plataforma compartida y gastos administrativos reducidos, porque simplemente hay menos que gestionar, configurar y mantener. Cuando todas las unidades comerciales operan dentro de una organización, las integraciones son internas en vez de interinstitucionales, el uso compartido de datos es nativo y la huella total de sandboxes, asistencia y herramientas de regulación permanece proporcionalmente más pequeña. Las arquitecturas de múltiples organizaciones, aunque a veces son necesarias para la geografía, el cumplimiento normativo o la separación organizativa, introducen un efecto multiplicador en algunas categorías de costes. Cada organización adicional aporta sus propios requisitos de licencia, su propio estado de sandbox, su propio gasto de integración y su propio esfuerzo administrativo, y demanda herramientas más sofisticadas para gestionar la implementación entre organizaciones, la federación de identidad y la sincronización de datos. Comprenda el coste total real de propiedad de cada organización adicional antes de tomar una decisión arquitectónica difícil y costosa de revertir.

Los costes de API e integración se encuentran entre los factores de costes más subestimados en un ecosistema de Salesforce. La conexión de Salesforce a un sistema externo puede parecer sencilla, pero los requisitos de integración complejos acumulan rápidamente costes entre licencias de middleware, esfuerzo de desarrollo, mantenimiento continuo y el consumo de API que fluye desde cada intercambio de datos. Las empresas con muchos sistemas integrados, altos volúmenes de datos o requisitos de sincronización casi en tiempo real están especialmente expuestas. El enfoque arquitectónico importa aquí. Las integraciones precisas y conversacionales que realizan llamadas de API pequeñas y frecuentes son más caras y frágiles que los patrones dirigidos por eventos o masivos bien diseñados que minimizan los recorridos de ida y vuelta, y las diferencias compuestas a medida que se multiplican las aplicaciones conectadas. Gobierne estándares de diseño de integración, consolide plataformas de integración donde sea posible y revise regularmente si las integraciones existentes aún funcionan con la eficiencia que se diseñaron originalmente.

Una arquitectura sostenible requiere más que optimizaciones de diseño iniciales. Exige supervisión continua y rendición de cuentas estructurada. La supervisión y la regulación de costes son el marco que convierte la optimización de un ejercicio puntual en una práctica operativa continua. El seguimiento coherente y la propiedad clara reducen el riesgo de superaciones de costes inesperadas de modo que cada dólar gastado se alinea con el valor comercial.

Cree visibilidad sobre patrones de gasto a través de paneles accesibles tanto para equipos técnicos como para partes interesadas comerciales, de modo que las conversaciones de inversión se basen en datos en vez de en facturas. La visibilidad de costes inicia una conversación dirigida por datos acerca de prioridades de inversión y oportunidades de optimización, y funciona mejor cuando hay tres vistas diferentes disponibles. Los paneles de utilización de licencias revelan usuarios inactivos, usuarios con sobrelicencia y desajustes de tipo de licencia, que son las oportunidades de optimización que se ocultan dentro de un recuento de usuarios sin licencia. Los paneles de capacidad muestran el almacenamiento, la API y el consumo de procesamiento con tendencias de crecimiento, de modo que los equipos optimizan antes de que un límite provoque un fallo en lugar de después. Los paneles de inversión muestran el gasto por unidad comercial, los costes de entorno por el equipo propietario, los costes adicionales frente a su utilización y el gasto proyectado basándose en el crecimiento actual, lo que convierte una conversación de presupuesto en una conversación de asignación.

Estos paneles pueden proceder de una variedad de herramientas, incluyendo Digital Wallet e informes personalizados que consultan metadatos. La herramienta importa menos que la disciplina de aflorar los datos donde se toman decisiones. Comparta los paneles con las partes interesadas comerciales y el liderazgo para crear la transparencia para un debate de inversión fundamentado en vez de un debate presupuestario reactivo. Un equipo financiero que ve patrones de utilización puede optimizar el gasto. Un equipo que solo ve una factura total solo puede cortarla.

Implemente la concienciación sobre el gasto en toda la empresa, incluyendo alertas proactivas que marcan la optimización antes de superar los límites:

Los presupuestos de licencias establecen objetivos de asignación por departamento con alertas a medida que se acercan a la capacidad, de modo que el aprovisionamiento no controlado no se detecta solo en la renovación.
Los presupuestos de almacenamiento supervisan el índice de crecimiento con alertas cuando las tendencias proyectan superar los límites antes del siguiente ciclo de renovación. Estas alertas proporcionan advertencias por adelantado de modo que el archivado se pueda implementar antes de que se produzcan sobrecargas.
Los presupuestos de API realizan un seguimiento del consumo en comparación con los límites con alertas en umbrales de utilización de ejemplo como el 70% y el 85%, de modo que la optimización es proactiva en vez de una respuesta de emergencia después de que los límites causen fallos.
Los presupuestos sandbox controlan la proliferación del entorno a través de límites de asignación y procesos de aprobación.

Los controles de presupuesto crean conciencia de costes sin bloquear la inversión necesaria. Los umbrales de alerta proporcionan alertas tempranas que permiten una optimización cuidadosa en vez de una aleatorización reactiva.

La asignación de costes crea responsabilidad y toma de decisiones fundamentadas entre unidades comerciales, y las empresas la implementan a través de uno de los dos modelos que difieren en la cantidad de responsabilidad que imponen. Showback reporta costes por unidad comercial sin aplicar un cargo financiero real. Crea transparencia y promueve debates conscientes de los costes y la priorización de la optimización sin la disputa de la facturación interna, lo que se adapta a una empresa que prefiere la gestión de costes colaborativa a la responsabilidad financiera. La devolución de cargos asigna costes reales a unidades comerciales y crea responsabilidad financiera directa por decisiones de consumo. Impulsa un comportamiento de optimización más sólido porque los costes afectan directamente a los presupuestos departamentales, pero requiere una metodología de asignación precisa para evitar disputas sobre quién paga por qué. De cualquier forma, las reglas de asignación siguen la misma lógica: costes de licencia por departamento de usuario, costes de entorno por propiedad del equipo de desarrollo, costes de integración por el proceso comercial que consume la integración y costes de desarrollo por la iniciativa que financia el trabajo. Cuando esas reglas están ausentes, cada coste recae en un presupuesto de TI central y las partes interesadas comerciales tratan la plataforma como gratuita, que es precisamente la condición que produce solicitudes realizadas sin conciencia de costes.

Adapte las prácticas de FinOps de nube a la economía de la plataforma Salesforce para crear una función de optimización continua en vez de una limpieza periódica. Cinco prácticas tienen el peso.

La colaboración interfuncional entre finanzas, arquitectura y partes interesadas comerciales garantiza que las decisiones de costes ponderen el valor comercial junto con el gasto. Aporta experiencia financiera en debates de arquitectura y comprensión técnica en planificación presupuestaria.
Una cadencia de optimización continua evita la desviación de costes a través de ciclos de revisión regulares: una revisión de anomalía mensual que detecta picos de gasto, una auditoría de utilización trimestral que valida asignaciones de licencias y uso de capacidad, y una evaluación de TCO integral anual que reajusta el gasto con prioridades estratégicas.
Las decisiones de inversión dirigidas por datos utilizan datos de utilización y modelos de TCO en vez de suposiciones o hábitos históricos. Estas decisiones sustituyen "siempre lo hemos hecho así" por el análisis de si el gasto corriente ofrece un valor óptimo.
La automatización de la supervisión de costes reduce el esfuerzo manual en el seguimiento de la utilización, la identificación de oportunidades de optimización y la generación de informes, de modo que la práctica se amplía con la complejidad organizativa sin un crecimiento lineal del número de empleados.
La educación de conciencia de costes ayuda a los equipos a comprender cómo las decisiones de arquitectura afectan al coste total de propiedad, porque un arquitecto que comprende los costes diseña mejores compensaciones y un desarrollador que comprende la economía de plataforma redacta una automatización más eficiente.

Integre la conciencia de costes en el proceso de revisión de arquitectura de modo que las implicaciones de inversión sean visibles junto con consideraciones funcionales y técnicas en vez de descubiertas después de la implementación. Incluya una evaluación de impacto de costes en los registros de decisiones de arquitectura que documentan las principales opciones de diseño. Requerir una proyección de TCO para soluciones que superan un umbral de inversión definido. Evalúe las implicaciones de las licencias durante el diseño, determinando si un enfoque requiere licencias premium o complementos antes de comprometerse. Evalúe el coste de integración antes de adoptar un patrón que afecte al consumo de API o a las licencias de middleware. Una Junta de revisión de arquitectura que lleva una perspectiva de costes junto con requisitos funcionales y no funcionales produce decisiones de inversión mejor alineadas. Trate el coste como una entrada a una decisión arquitectónica en vez de como su único impulsor, de modo que las empresas inviertan adecuadamente en lo que importa y eviten el desperdicio en lo que no.

La sostenibilidad de Cloud Computing se centra en minimizar el impacto medioambiental de la infraestructura digital a través del uso eficiente de los recursos, y se alinea de forma natural con el valor por coste: la misma eficiencia que baja el consumo de recursos también baja el coste. Salesforce y los arquitectos comparten la responsabilidad de los resultados de sostenibilidad. Salesforce gestiona la infraestructura del centro de datos, incluyendo la optimización de la eficacia del uso energético, la eficiencia de refrigeración y la gestión del ciclo de vida del hardware, junto con la agrupación de recursos de múltiples arrendatarios y mejoras de eficiencia a nivel de plataforma. Influye en los patrones de consumo de recursos de sus soluciones en ese entorno de múltiples arrendatarios.

La relación entre una solución individual y las emisiones del centro de datos es indirecta, y ser preciso al respecto importa. Las optimizaciones de un único arrendatario no reducen directamente las emisiones del centro de datos. Lo que hacen es contribuir a un efecto agregado: Las ganancias de eficiencia entre todos los arrendatarios permiten a Salesforce operar su infraestructura con una utilización más alta y aplazar la expansión de la capacidad. Por lo tanto, las mediciones de eficiencia de recursos, incluyendo consultas SOQL, tiempo de CPU, consumo de pila y almacenamiento, sirven como indicadores proxy para la sostenibilidad. La eliminación de desechos informáticos mejora el rendimiento y el coste, y contribuye a los objetivos de eficiencia de toda la plataforma. Los principios de diseño en este pilar, incluyendo masificación, consultas selectivas, almacenamiento en caché, procesamiento asíncrono y ciclo de vida de datos disciplinado, crean soluciones que consumen menos recursos. La sostenibilidad no es una iniciativa separada anclada en la arquitectura. Es el aspecto de la eficiencia de recursos cuando la mide con el impacto medioambiental en vez de solo con el coste financiero.

Varias prácticas arquitectónicas conllevan la mayor parte del valor de sostenibilidad, y cada una también mejora el rendimiento o el coste, por lo que pertenecen al mismo pilar.

La automatización inactiva consume recursos de infraestructura sin entregar ningún valor comercial. Desencadena que procesan registros irrelevantes, flujos de trabajo que se ejecutan innecesariamente y trabajos programados que se ejecutan cuando no existe trabajo, todo ello desperdicia computación, almacenamiento y energía. El remedio es una auditoría de automatización trimestral con criterios explícitos para lo que cuenta como no utilizado: ninguna ejecución en los últimos 90 días, trabajos por lotes que procesan de forma coherente cero registros y automatización sustituida por implementaciones más recientes pero nunca desactivada. Documente cada desactivación de modo que pueda revertirse si vuelve a surgir un requisito comercial. Una empresa que transporta docenas de Process Builder que quedaron de implementaciones anteriores, la mayoría sin ejecuciones en el último año, paga por evaluar cada uno de ellos en cada guardado de registro relevante.

La programación de operaciones intensivas en recursos durante las horas de menor producción distribuye la carga entre plazos de tiempo. En un entorno de múltiples arrendatarios, esta disciplina mejora la capacidad de respuesta de la plataforma durante el horario de oficina y, de forma agregada entre arrendatarios, permite a Salesforce operar infraestructura con una utilización media superior. Programe el archivado por lotes, el enriquecimiento y la limpieza para plazos de bajo uso, escalone los trabajos en vez de iniciar 20 a medianoche y provocar un pico de procesamiento, y prefiera patrones dirigidos por eventos en lugar de sondeos programados de modo que no se empleen ciclos comprobando si hay trabajo que no está allí.

Calcular el mismo valor desperdicia repetidamente ciclos de CPU y capacidad de infraestructura. Calcule una vez, almacene en caché el resultado y reutilícelo entre transacciones y usuarios. Caché de plataforma sirve datos de referencia consultados repetidamente, los valores de acumulación en caché evitan consultas de agregación en tiempo real donde la precisión casi en tiempo real es suficiente, los campos de fórmula se vuelven a calcular de forma dinámica en el acceso a registros en vez de almacenar un valor y requerir automatización para mantenerlo, y Lightning Data Service elimina solicitudes de servidor redundantes en el cliente. Cada cálculo evitado es capacidad devuelta a la plataforma.

El almacenamiento de datos consume recursos de infraestructura y degrada el rendimiento de las consultas a medida que crece. Las políticas de retención que archivan o eliminan datos que ya no son necesarios para operaciones activas mantienen tablas activas pequeñas y consultas rápidas. Archive registros antiguos en Big Objects o almacenamiento externo en un trabajo programado, elimine de forma permanente cuando cumpla en vez de basarse en la eliminación gradual que continúa consumiendo almacenamiento y configure la retención de Seguimiento de auditoría de campo por campo en vez de aplicar un máximo que almacena mucho más historial del que requiere el cumplimiento. Al igual que con el procesamiento programado, las decisiones de archivado individuales no reducen directamente el uso energético del centro de datos, pero agregar disciplina de ciclo de vida de datos entre todos los arrendatarios mejora la eficiencia de la plataforma y aplaza la expansión de la infraestructura de almacenamiento.

Las integraciones externas consumen recursos tanto en Salesforce como en los sistemas a los que se conectan. Cambiar Captura de datos y otros patrones dirigidos por eventos eliminan las llamadas de sondeo que comprueban repetidamente cambios y no encuentran ninguno, lo que reduce el consumo de API, beneficia los límites reguladores y elimina el derroche de cálculo. Los patrones de API compuestos agregan múltiples operaciones en una sola llamada, la API masiva v2 procesa grandes volúmenes de forma mucho más eficiente que miles de llamadas de REST individuales y la lógica de reintento con retroceso exponencial evita martillar un sistema externo en dificultades. Una integración única que sondea cada cinco minutos y no encuentra nada que hacer la mayoría de las veces es pura basura, mientras que la misma integración dirigida por eventos de cambio procesa solo cambios reales.

Las arquitecturas de agentes consumen recursos computacionales a través de una inferencia de modelo de lenguaje grande, y se aplica la misma mentalidad de eficiencia. Minimice la longitud de las solicitudes, resuma el historial de conversaciones en vez de incluir transcripciones literales completas que crecen sin límites, utilice el modelo más pequeño suficiente para una tarea en vez de utilizar de forma predeterminada el más capaz y almacene en caché datos de referencia y respuestas deterministas. La recuperación de 50 resultados de búsqueda vectorial cuando solo se evalúan 5 gasta recursos de inferencia y recuperación sin valor añadido, de modo que configure límites de recuperación para coincidir con el uso real.

La sostenibilidad, como el resto de este pilar, requiere supervisión continua en vez de un pase puntual, porque los patrones de consumo de recursos cambian a medida que evolucionan las soluciones, crecen los volúmenes de datos y se amplían las poblaciones de usuarios. La supervisión solo importa cuando desencadena acciones. Defina umbrales con capacidad de acción para cada medición (recuento de consultas SOQL que supera un objetivo por transacción, crecimiento del almacenamiento más allá de un porcentaje mensual o un índice de aciertos de caché que cae por debajo de un objetivo) y documente qué optimizaciones perseguir primero. Centre el esfuerzo en transacciones de gran volumen y automatización ejecutada con frecuencia, donde las mejoras de eficiencia tienen el mayor impacto agregado. Process Builder alcanzó el final de la asistencia el 31 de diciembre de 2025 Migre Process Builder restantes a Flow; no solo los desactive.

Utilice esta lista de comprobación para evaluar si una solución devuelve el valor máximo por coste. Combina las prácticas de eficiencia de los recursos y disciplina en función de los costos de este pilar en un examen, ya que las dos son una sola decisión.

Modelado de valor y coste

Conecte cada inversión significativa de Salesforce con un resultado comercial mensurable.
Modele el coste total de propiedad entre categorías directas, indirectas, puntuales y continuas antes de comprometerse con un enfoque.
Compare TCO para la línea base y para alternativas arquitectónicas optimizadas en un horizonte de 3 a 5 años.
Aplique una evaluación de construcción contra compra coherente que pondere la diferenciación estratégica, el tiempo de valor y el coste de salida en vez de basarse en juicios ad hoc.

Eficiencia de recursos

Diseñe transacciones para operar cómodamente dentro de límites reguladores bajo carga máxima y volúmenes de datos máximos.
Haga que las consultas sean selectivas en campos indexados y valide con la Herramienta Plan de consulta antes de implementar en objetos de gran tamaño.
Agrupe todas las operaciones de datos y seleccione el procesamiento asíncrono deliberadamente donde los límites síncronos lo requieran.
Almacene en caché datos de referencia a través de Caché de plataforma y Servicio de datos Lightning para evitar consultas repetidas y un nuevo cálculo.
Evite el sesgo de datos distribuyendo la carga y supervisando objetos de gran volumen.
Centralice la lógica de desencadenador, servicio y selector de modo que la lógica comercial siga siendo comprobable y barata de cambiar.
Defina un ciclo de vida de datos completo desde la creación hasta el archivado y supervise el consumo de almacenamiento a nivel de objeto.

Licencia y consumo

Haga coincidir cada usuario con el tipo de licencia que requiere su trabajo, y audite funciones, actividad de inicio de sesión y uso de funciones regularmente.
Establezca la visibilidad de los índices de quema de créditos de consumo y diseñe automatizaciones y agentes para invocar servicios medidos de forma eficiente.
Gobierne el aprovisionamiento de entornos sandbox con políticas claras de propiedad, cadencia de actualización y clausura.
Comprenda el multiplicador de costes de múltiples organizaciones completo antes de agregar una organización, y favorezca la integración masiva o dirigida por eventos sobre patrones de chat.

Supervisión y gobernanza

Proporcione paneles de coste y capacidad accesibles para equipos técnicos y partes interesadas comerciales.
Establezca alertas de presupuestos para licencias, almacenamiento, consumo de API y entornos sandbox de modo que la optimización sea proactiva en vez de reactiva.
Establezca la devolución o devolución de cargos de modo que la asignación de costes cree responsabilidad entre unidades comerciales.
Adopte una cadencia de FinOps: revisión mensual de anomalías, auditoría de utilización trimestral y evaluación integral anual de TCO.
Integre la evaluación de impacto de costes en revisiones de arquitectura y registros de decisiones de arquitectura.

Optimización y sostenibilidad continuas

Trate la optimización como una práctica continua y valide que las inversiones de optimización anteriores entregaron su retorno esperado.
Elimine la automatización no utilizada y el cálculo redundante a través de auditorías regulares.
Realice un seguimiento del consumo de recursos a lo largo del tiempo y defina umbrales con capacidad de acción que desencadenen la optimización cuando una medición los cruce.

Comparta sus comentarios sobre el Marco bien diseñado.