Optimización de recursos y costos

La optimización de recursos y la optimización de costos funcionan conjuntamente para que su compañía alcance el máximo valor por costo. Salesforce gestiona la infraestructura de múltiples arrendatarios, aplica los límites reguladores que mantienen la plataforma justa para cada arrendatario y asigna precios al acceso a través de licencias y créditos de consumo. Lo que optimiza es el valor que obtiene de vuelta: cuánto resultado de negocio 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 costos 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 costo da forma a cada decisión arquitectónica que toma. Cuando comprende el costo total de propiedad, realiza mejores compensaciones entre capacidad e inversión. Asigne el tamaño adecuado a las soluciones para que coincidan con los requisitos de negocio 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 en 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 costo o un recurso", pero "¿tiene este ingreso una devolución apropiada?"

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

El desempeño se degrada a medida que crecen los volúmenes de datos.
Los tiempos de espera de consultas emergen en unos 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 a la vez un problema de fiabilidad y un problema de costo, porque 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
Alineación de licencias y consumo de tamaño correcto con uso real
Modelado de costo completo antes de confirmar un enfoque
Monitoreo del gasto de forma continua frente a resultados de negocio

Estas prácticas son complejas. Los equipos que crean conciencia de costos y eficiencia de recursos en su diseño entregan más capacidad 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 costos conecta con otros pilares arquitectónicos directamente. Operational Excellence reduce los costos 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 de negocio y el valor de cumplimiento normativo. Juntos, estos pilares ayudan a las compañías 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 costos en la plataforma.

Optimice el costo total de propiedad. El costo total de propiedad (TCO) se amplía más allá de las comisiones de suscripción a créditos de consumo, costos de implementación, costos operativos, gastos de integración y esfuerzo de gestión de cambios. Evalúe decisiones utilizando análisis de TCO para revelar la imagen de inversión completa a lo largo de la vida útil de una solución. A veces, una mayor inversión inicial reduce sustancialmente los costos operativos en curso, y el análisis de TCO aflora esa compensación. Optimice el valor a largo plazo, no la minimización de costos a corto plazo.
Alinee el gasto con el valor de negocio. Conecte cada inversión de Salesforce con un resultado de negocio mensurable. El gasto de licencia permite la productividad de los usuarios 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 costos 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 desempeño 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. Las consultas eficientes, el procesamiento de registros de forma masiva (masificación), el almacenamiento en caché y el 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 costos sostenible: Los desechos eliminados de los recursos aprovisionados mejoran tanto el desempeño como el TCO a largo plazo.
Licencias de tamaño correcto y consumo para uso real. Haga coincidir 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 figuran entre 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 costos basados en el consumo predecibles.
Establecer la gobernanza financiera y una cultura de costos. Gestione los gastos de Salesforce como una inversión estratégica a través de la supervisión activa y la rendición de cuentas compartida. La gobernanza financiera aporta análisis de costo-beneficio en decisiones de diseño en vez de descubrir costos después de la implementación. La conciencia de costos es una responsabilidad compartida entre partes interesadas de negocio, arquitectos y desarrolladores que ponderan las implicaciones de costos 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.
Practique la optimización continua. La optimización es una práctica continua, no un ejercicio puntual. Monitoree el gasto y el consumo de recursos a través de tableros accesibles para partes interesadas técnicas y de negocio. Configure alertas que se desencadenan cuando el gasto de consumo alcanza umbrales antes de que el consumo desbocado pase desapercibido. Las revisiones regulares 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 de negocio 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 múltiples: Salesforce garantiza un uso compartido de CPU, memoria y conexión de base de datos justo entre todos los clientes en infraestructura compartida, monitorea el consumo de arrendatarios y aplica límites que evitan que cualquier arrendatario único degrade el desempeño para otros.
Arquitectura de límite regulador: Los límites aplicados por plataforma (100 consultas SOQL por transacción síncrona, tiempo de CPU de 10 segundos, tamaño de pila de 6 MB) 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 los patrones de consulta comunes y el optimizador se adapta a los 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 desempeño de plataforma: Salesforce optimiza continuamente el código de plataforma principal, la ejecución de consultas, los tiempos de respuesta de API y el desempeño 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 computación 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 posee 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 en 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 de negocio desde la capacidad de computación, almacenamiento y API que ya paga, y ese es el mecanismo que mantiene la optimización de costos sostenible en vez de un recorte de presupuesto puntual. El cálculo derrochador, por el contrario, consume recursos de infraestructura sin entregar valor de negocio y sus compuestos de costos. El desempeño 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: desempeño, organización de código, empaquetado y datos. Cada una es una decisión de valor por costo 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 costos.

La optimización del desempeño comienza con un cambio en el modo en que 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 desempeño 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 funciones futuras, 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 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 se 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 ajustan a medida que un objeto crece más allá de su primer millón de registros. La arquitectura para la selectividad significa filtrar en campos indexados como su criterio principal y validar con la Herramienta de 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 cualquier otro arrendatario y cualquier 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 gratuito, 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 fuerza las decisiones de experiencia de usuario que no dependen de la confirmación instantánea. Requiere una gestión y un monitoreo explícitos de errores, ya que un fallo aflora 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 de negocio abarca varias transacciones. La decisión de valor por costo es sopesar esa complejidad agregada con la capacidad que el trabajo necesita genuinamente 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. Apex por lotes es para volumen. Procesa millones de registros dividiéndolos en partes, cada una 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í. Colocable 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. Los eventos de plataforma son para desvincular: un productor emite un evento sin saber o esperar a sus consumidores. Utilice este patrón para la notificación entre sistemas y para la separación del 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 sencillo 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 polivalente. Haga coincidir el mecanismo asíncrono con la forma del trabajo. De lo contrario, negocia un problema de límite regulador para la coherencia y los costos de monitoreo 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. Almacene 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 establezca 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 caché nunca sirva un valor obsoleto lo suficientemente largo como para importar. Una caché que es demasiado agresiva cambia una ganancia de desempeño por un riesgo de corrección, y una caché con un índice de aciertos deficiente emplea almacenamiento sin devolver capacidad, por lo que el índice de aciertos es una medición para monitorear 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 coincidencia de caché es capacidad de cálculo y API que no tiene que gastar, siempre que el valor que devuelve siga siendo correcto.

El sesgo de datos es un punto crítico de desempeño creado por una distribución de registros desequilibrada. Cuando un único registro principal acumula más de 10.000 secundarios, el desempeño 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 estricto. Le indica distribuir la carga entre múltiples principales, monitorear 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 por 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 desempeño 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 asigna un nombre al desencadenador específico y el objeto implicado. ApexGuru aplica 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 las consultas aparecen dentro de bucles u otros defectos de desempeño se detectan. Event Monitoring revela tendencias de consumo a lo largo del tiempo, y Proactive Monitoring, una función de Plan de éxito de firma, evalúa continuamente la organización para riesgos de desempeño y capacidad de ampliación.

La organización de código es una decisión de costo 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 controlador de desencadenadores centraliza la lógica de desencadenadores en clases de controladores 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 de negocio en clases que exponen operaciones invocables desde un desencadenador, un extremo de REST, un flujo invocable o un trabajo por lotes, de modo que una regla de negocio 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 nombrada explícita.

Los errores DML mixtos son un riesgo organizativo distinto que merece la pena diseñar de forma explícita. 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 el 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 de negocio y aislar el DML de configuración en pruebas.

Las opciones de empaquetado determinan el costo de desarrollo a largo plazo y la reutilización que puede lograr en una compañía. 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 de negocio 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 amplía 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 automatizaciones en Flow Builder a partir de funciones creadas por el desarrollador, lo que reduce la duplicación y acorta el mundo declarativo y programático. 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 se necesite.

El crecimiento de datos no gestionados es el origen más común de la degradación gradual del desempeño y dirige el costo 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 costo de un acoplamiento más estrecho. Las búsquedas proporcionan flexibilidad al costo 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 hasta la archivación en vez de permitir que los objetos acumulen registros de forma indefinida, ya que un objeto que crece hasta los millones sin una estrategia de archivación produce a la larga tiempos de espera de consultas, consultas no selectivas y vistas de lista que agotan el tiempo de espera.

Seleccione el mecanismo de archivo solo después de liquidar el cumplimiento. Antes de seleccionar un mecanismo, confirme si los requisitos de residencia de datos, derecho a 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 mediante 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 compañía. Monitoree 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 costos equilibra el valor de negocio con el costo de la solución, y depende de establecer un costo preciso en primer lugar. Para ello, tenga en cuenta cada componente de costo, ya que mirar un único componente como costo de licencia lleva a una comprensión incorrecta de lo que cuesta la solución en realidad. Una tarifa de licencia modesta puede ocultar costos 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. Costo total de propiedad es el modelo que captura la imagen completa. Abarca todos los costos asociados con una solución de Salesforce a lo largo de su vida útil y los separa en costos directos, que están claramente asociados con la solución, y costos indirectos, que son reales pero fáciles de pasar por alto. El modelado convierte una estimación de costo en una decisión de arquitectura fundamentada que pondera el valor a largo plazo en vez de solo el gasto inicial.

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

Los costos 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 costo fundamental porque las diferencias por usuario son significativas. Los costos 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 costos de implementación cubren el diseño de soluciones, el desarrollo, las pruebas, la migración de datos y la capacitación. Son predominantemente puntuales pero crean obligaciones de mantenimiento continuas proporcionales a la complejidad. Las compañías subestiman sistemáticamente el esfuerzo de implementación porque se centran en el desarrollo y subvaloran las pruebas y la capacitación.
Los costos operativos cubren la administración, la asistencia al usuario, el monitoreo, 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 costos de mantenimiento cubren la mejora, la solución de deudas técnicas, 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 la convierte en la categoría de costos continua más grande.
Los costos 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 se compone de mantenimiento a medida que aumenta el conteo del sistema.
Los costos de cambio cubren el rediseño de procesos de negocio, la gestión de cambios, la adopción y la coordinación de partes interesadas. Aumentan con el alcance entre unidades de negocio y regiones, y se omiten con frecuencia porque se manifiestan como esfuerzo de equipo de negocio.

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

Los costos organizativos son las inversiones que impulsan el éxito de Salesforce pero nunca aparecen en una factura de Salesforce. Incluyen salarios de equipo internos para administradores, desarrolladores y arquitectos, infraestructura de desarrollo como control de versiones y herramientas de CI/CD, capacitación y certificación, mantenimiento y desarrollo de habilidades, y el costo 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. Aparece como la innovación que nunca se envió.

Los intereses de deuda técnica son el costo 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 de negocio. Los equipos que aplazan las mejoras de arquitectura el tiempo suficiente descubren 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 costos 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 el monitoreo de la utilización de licencias y la adopción de funciones revela funciones para invertir más o retirarse para redirigir la capacidad.

La visibilidad de costos integral requiere atribuir partidas directas y estas indirectas, porque solo la imagen completa admite una decisión de inversión sólida.

Cree modelos de TCO para su línea base y para alternativas arquitectónicas optimizadas antes de confirmar un enfoque. Los modelos que proyectan costos de 3 a 5 años con supuestos documentados le permiten comparar opciones sistemáticamente. Ejecute análisis de confidencialidad en los supuestos que más importan para determinar las variaciones y los límites de las estimaciones de costos. Planifique volver a visitar decisiones cuando cambien las condiciones. La disciplina de escribir los supuestos 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 costo 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 la fuente 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 construcción personalizada comparable. El proveedor mantiene las funciones, incluyendo la compatibilidad de versiones de plataforma, sin esfuerzo del cliente. Las funciones están probadas 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 compañía 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 costo de suscripción continuo para modelar.

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 ventaja es que la compañía 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 costos de mantenimiento continuos además de la responsabilidad completa de la compatibilidad de la versión. Totales del proyecto de 3 a 5 años para ambos de modo que la comparación refleje la inversión completa en vez del gasto inicial, que suele favorecer cualquier opción que pareciera más barata el primer día.

Más allá del costo sin procesar, 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 una mercancía que se adquiere mejor.
El tiempo para valorar favorece la compra cuando se necesita una capacidad 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 costo de salida favorece opciones que mantienen la flexibilidad, porque 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 para la ecuación de valor por costo justo como computación y almacenamiento, y están entre los orígenes 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 compañía 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 compañías, 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 corregir 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 compañía.

La optimización de créditos de consumo importa cada vez más a medida que las compañías adoptan Agentforce, Data 360 y otras funciones con tecnología de IA que asignan precios por uso en vez de por asiento. Los conjuntos de créditos pueden agotarse sorprendentemente rápido cuando los equipos diseñan sus procesos de forma ineficiente o no monitorean sus patrones de uso. A diferencia de un conteo de licencias fijo, el consumo puede aumentar sin tomar 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 costo, expresada en términos de consumo.

La estrategia de entorno y sandbox es una decisión de recurso con consecuencias de costo directo, y un modelo de entrega de Salesforce maduro requiere una estrategia de entorno bien estructurada. Los entornos de desarrollo, prueba, organización y producción tienen 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 gran tamaño o de larga duración, y eleva el costo de formas que atrapan a las compañías 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 de forma activa 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 por la comodidad, y establezca políticas claras para la propiedad, la cadencia de actualización y el desmantelamiento de modo que el estado se mantenga ajustado al tamaño del trabajo.

La arquitectura de múltiples organizaciones multiplica el costo. Una arquitectura de una sola organización 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 de negocio operan en una organización, las integraciones son internas en vez de entre organizaciones, el uso compartido de datos es nativo y la huella total de sandboxes, asistencia y herramientas de gobernanza se mantiene 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 costos. Cada organización adicional aporta sus propios requisitos de licencia, su propio estado de sandbox, su propia carga 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 costo total real de propiedad para cada organización adicional antes de tomar una decisión arquitectónica difícil y costosa de revertir.

Los costos de API e integración están entre los factores de costo 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 costos entre licencias de middleware, esfuerzo de desarrollo, mantenimiento continuo y el consumo de API que fluye desde cada intercambio de datos. Las compañías 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 detalladas y confusas que realizan llamadas de API pequeñas con frecuencia 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 los 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 misma eficiencia que se diseñaron originalmente.

Una arquitectura sostenible requiere más que optimizaciones de diseño iniciales. Exige supervisión continua y responsabilidad estructurada. El monitoreo y la gobernanza de costos son el marco de trabajo 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 costos inesperadas de modo que cada dólar gastado se alinea con el valor de negocio.

Cree visibilidad sobre patrones de gasto a través de tableros accesibles para equipos técnicos y partes interesadas de negocio, de modo que las pláticas de inversión se basen en datos en vez de en facturas. La visibilidad de costos inicia una plática dirigida por datos acerca de prioridades de inversión y oportunidades de optimización, y funciona mejor cuando hay tres vistas distintas disponibles. Los tableros 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 conteo de usuarios sin licencia. Los tableros 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 cause un fallo en lugar de después. Los tableros de inversión muestran el gasto por unidad de negocio, los costos de entorno por el equipo propietario, los costos complementarios frente a su utilización y el gasto proyectado basándose en el crecimiento actual, lo que convierte una plática de presupuesto en una plática de asignación.

Estos tableros pueden proceder de una variedad de herramientas, incluyendo Digital Wallet y reportes personalizados que consultan metadatos. La herramienta importa menos que la disciplina de aflorar los datos donde se toman decisiones. Comparta los tableros con las partes interesadas de negocio y el liderazgo para crear la transparencia para un debate de inversión fundamentado en vez de un debate presupuestario reactivo. Un equipo de finanzas 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 compañía, 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 descubre solo en la renovación.
Los presupuestos de almacenamiento monitorean 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 anticipado de modo que el archivado se puede implementar antes de que se produzcan sobrecargas.
Los presupuestos de API realizan un seguimiento del consumo frente a 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 costos sin bloquear la inversión necesaria. Los umbrales de alerta proporcionan alertas tempranas que activan la optimización reflexiva en vez de la codificación reactiva.

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

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 entre funciones entre finanzas, arquitectura y partes interesadas de negocio garantiza que las decisiones de costos ponderen el valor de negocio junto con el gasto. Aporta experiencia financiera en debates de arquitectura y comprensión técnica en la planificación presupuestaria.
Una cadencia de optimización continua evita la desviación de costos 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 realinea 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 supuestos o hábitos históricos. Estas decisiones sustituyen "siempre lo hemos hecho de esta manera" por análisis de si el gasto corriente ofrece un valor óptimo.
La automatización del monitoreo de costos reduce el esfuerzo manual en el seguimiento de la utilización, la identificación de oportunidades de optimización y la generación de reportes, de modo que la práctica se amplía con la complejidad organizativa sin crecimiento lineal del conteo.
La educación sobre los costos ayuda a los equipos a comprender cómo afectan las decisiones de arquitectura al costo total de propiedad, porque un arquitecto que comprende los costos diseña mejores compensaciones y un desarrollador que comprende la economía de la plataforma redacta una automatización más eficiente.

Integre la conciencia de los costos en el proceso de revisión de la 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 costos 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 costo de integración antes de adoptar un patrón que afecta al consumo de API o las licencias de middleware. Una Junta de revisión de arquitectura que lleva una perspectiva de costos junto con requisitos funcionales y no funcionales produce decisiones de inversión mejor alineadas. Trate el costo como una entrada a una decisión arquitectónica en vez de como su único impulsor, de modo que las compañías inviertan adecuadamente en lo que importa mientras evitan el desperdicio en lo que no.

La sostenibilidad de la computación en nube 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 costo: la misma eficiencia que reduce el consumo de recursos también reduce el costo. 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 la 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 es importante ser preciso al respecto. Las optimizaciones de un solo arrendatario no reducen directamente las emisiones del centro de datos. Lo que hacen es contribuir a un efecto agregado: Las mejoras de eficiencia entre todos los arrendatarios permiten a Salesforce operar su infraestructura con una utilización superior y aplazar la expansión de la capacidad. Las mediciones de eficiencia de recursos, incluyendo consultas SOQL, tiempo de CPU, consumo de pila y almacenamiento, por lo tanto, sirven como indicadores proxy para la sostenibilidad. La eliminación de desechos computacionales mejora el desempeño y el costo, 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 atornillada en la arquitectura. Es el aspecto de la eficiencia de los recursos cuando la mide con el impacto medioambiental en vez de solo con el costo financiero.

Varios estudios de arquitectura tienen la mayor parte del valor de sostenibilidad, y cada uno también mejora el desempeño o el costo, por lo que pertenecen al mismo pilar.

La automatización inactiva consume recursos de infraestructura sin entregar ningún valor de negocio. Los desencadenadores que procesan registros irrelevantes, flujos de trabajo que se ejecutan innecesariamente y trabajos programados que se ejecutan cuando no existe trabajo desperdician 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 de negocio. Una compañía 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 actividad 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 trabajos en vez de iniciar 20 a medianoche y provocar un pico de procesamiento, y prefiera patrones dirigidos por eventos sobre los sondeos programados de modo que no se emplee ningún ciclo comprobando si hay trabajo que no está allí.

El cálculo del 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 agregadas 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 desempeño de las consultas a medida que crecen. Las políticas de retención que archivan o eliminan datos ya no 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 continua que sigue 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 archivo individuales no reducen directamente el uso energético del centro de datos, pero la disciplina del ciclo de vida de los datos agregada 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. Captura de datos de cambios 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 a los límites reguladores y elimina el derroche de cálculos. 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 reintentar lógica 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 pláticas 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 tomar como valor predeterminado 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 monitoreo continuo 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. El monitoreo solo importa cuando desencadena acciones. Defina umbrales con capacidad de acción para cada medición (conteo 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 frecuentemente, donde las mejoras de eficiencia tienen la mayor repercusión agregada. Process Builder alcanzó el final de la asistencia el 31 de diciembre de 2025 Migre Process Builder restantes a Flow; no los desactive simplemente.

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

Modelado de valor y costo

Conecte cada inversión significativa de Salesforce con un resultado de negocio mensurable.
Modele el costo total de propiedad entre categorías directas, indirectas, puntuales y continuas antes de confirmar 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 coherente de construcción contra compra que sopesa la diferenciación estratégica, el tiempo de valor y el costo 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 con respecto a campos indexados y valide con la Herramienta de plan de consulta antes de implementar con objetos de gran tamaño.
De forma masiva 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 el recálculo.
Evite el sesgo de datos distribuyendo la carga y monitoreando objetos de gran volumen.
Centralice la lógica de desencadenador, servicio y selector de modo que la lógica de negocio se mantenga comprobable y barata de cambiar.
Defina un ciclo de vida de datos completo desde la creación hasta el archivado y monitoree 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 costos 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.

Seguimiento y gobernanza

Proporcione tableros de costo y capacidad accesibles para equipos técnicos y partes interesadas de negocio.
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 de cargos de modo que la asignación de costos cree responsabilidades entre unidades de negocio.
Adopte una cadencia FinOps: revisión mensual de anomalías, auditoría de utilización trimestral y evaluación anual integral del TCO.
Integre la evaluación de impacto de costos 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 desencadenan la optimización cuando una medición los cruza.

Comparta sus comentarios sobre el Marco de trabajo bien diseñado.