Cuándo usa Salesforce un índice
También en 19 idiomas
English · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Módulo 3 de 5 del capítulo Arquitectura de consultas y recuperación, capítulo 8 del curso Data Architect. Cada módulo se sostiene por sí solo. Anterior: Cómo encuentra Salesforce tus datos · Siguiente: Índices, skinny tables y rediseño
La pregunta que responde este módulo: ¿cuándo puede Salesforce usar un índice?
En el módulo anterior construimos el catálogo de fichas: qué es un índice, el coste de cada copia en cada guardado, y qué campos indexa Salesforce por ti, cuáles puedes pedir y cuáles no pueden tener índice en absoluto. Así que ya tenemos un índice. ¿Se puede usar en todas las circunstancias? No. Primero déjame contarte una historia.
El impulso del nitro
Sección titulada «El impulso del nitro »Imagina una carrera callejera. Dos coches uno al lado del otro, con los motores rugiendo. Cerca del final, un piloto pulsa un botón y el coche sale disparado y gana. Ese botón es el nitro: un aporte de combustible extra que le da al motor un arranque de velocidad durante unos segundos.
Pero el nitro no se dispara solo porque pulses el botón. Un sistema de nitro suele estar hecho para dispararse solo cuando se cumplen tres cosas a la vez:
- El sistema está instalado y encendido. Sin nitro en el coche, no hay impulso.
- El piloto tiene el pedal pisado a fondo. Písalo a medias y el sistema sigue apagado.
- El motor está en el rango de velocidad adecuado. Demasiado lento o demasiado rápido, y el sistema no se dispara.
Las tres, y el coche sale disparado. Falla una sola, y simplemente vas conduciendo.
Un índice es el nitro de tu consulta. Y funciona igual: tienen que cumplirse tres cosas para que Salesforce lo use.
| El coche | Tu consulta |
|---|---|
| El nitro está instalado y encendido | Hay un índice en el campo por el que filtras |
| El pedal está pisado a fondo | Preguntas de forma selectiva: igual a, empieza por |
| El motor está en el rango adecuado | No coinciden demasiados registros: estás por debajo del umbral |
Este módulo las trata de una en una. Empecemos por la primera.
¿Hay un índice?
Sección titulada «¿Hay un índice? »Empecemos por la pregunta para la que se construyó el catálogo. Acércate al mostrador y pide Fontanería básica. El bibliotecario va al cajón de fichas por título, encuentra la ficha, lee la estantería (B4), va hasta allí y baja el libro. Una ficha, un libro. En una biblioteca de 10 millones de libros, eso es una ficha y un libro en lugar de 10 millones de libros. Para eso sirve un índice, y es lo que hace Salesforce cuando filtras por un campo indexado: encuentra la entrada, lee a qué registro apunta y va directamente allí.
Ahora haz otra pregunta: “¿Me das todos los libros de Harbor Press?”. Tenemos cajones por título, por tema y por autor. ¿Hay un cajón por editorial? No. Entonces, ¿qué hace el bibliotecario? Recorre todos los pasillos y abre todos los libros. Eso es un recorrido de la tabla, y los tres cajones que pagamos no ayudaron en absoluto.
En Salesforce pasa lo mismo. Filtra por un campo que no está indexado, y los índices de los otros campos no pueden ayudar a ese filtro. Por eso importan las tablas del módulo anterior: antes de preocuparte por cualquier otra cosa, comprueba si el campo por el que filtras tiene un índice, estándar o personalizado. Esa es la primera de las tres: ¿está instalado el nitro?
Por título, hay un cajón: encuentra la ficha, coge el libro. Rápido.
Por editorial, no hay cajón: no hay coincidencia en el índice. Rodéalo y abre todos los libros: un recorrido de la tabla. Lento.
Preguntar al índice de la manera correcta
Sección titulada «Preguntar al índice de la manera correcta »Ahora supongamos que sí hay un cajón. El cajón de títulos, ordenado de la A a la Z. ¿Qué preguntas puede responder rápido?
- Encuentra el libro titulado Fontanería básica. Ve a la F, encuentra la ficha. Rápido.
- Encuentra todos los libros cuyo título empieza por “Fontanería”. Ve a la F, lee las fichas que empiezan por “Fontanería” y para cuando dejen de hacerlo. Rápido.
- Encuentra estos tres títulos. Tres viajes al cajón. Rápido.
- Y con un cajón de fichas por fecha, encuentra todos los libros añadidos este año: ve a la primera ficha de este año y lee hasta que termine el año. Rápido.
Cada una de esas preguntas le dice al bibliotecario por dónde empezar en el cajón. Ahora, algunas preguntas que el mismo cajón no puede responder así:
- Encuentra todos los libros cuyo título contiene “Fontanería”. “Avances en fontanería” está archivado en la A. “Guía de fontanería doméstica” está archivado en la G. El cajón está ordenado por cómo empieza un título, así que no hay ningún sitio por donde empezar a buscar. El cajón no puede responder, y el bibliotecario vuelve a recorrer todas las estanterías.
- Encuentra todos los libros cuyo título termina en “básica”. El mismo problema: el final de un título no te dice nada sobre dónde está archivado.
- Encuentra todos los libros que no son Fontanería básica. Casi todas las fichas coinciden. El cajón no acota nada.
- Encuentra todos los libros sin título. En los cajones de Salesforce, no hay ficha para un valor vacío a menos que alguien la pidiera (lo vimos en el módulo anterior).
Ninguna de estas le dice al bibliotecario por dónde empezar. En clase lo digo así: los índices funcionan de izquierda a derecha. Pide el principio del valor y el índice puede ayudar. Pide el medio, el final, o todo excepto un valor, y no puede: no hay coincidencia en el índice, y Salesforce vuelve a un recorrido de la tabla.
Empieza por: directo a la P. Una ficha, un libro. Rápido.
Contiene: no hay forma de entrar en el cajón, no hay coincidencia en el índice. Rodéalo y abre todos los libros: un recorrido de la tabla. Lento.
Esta es la misma lista en SOQL:
| Pregúntalo así | En SOQL | ¿Puede ayudar el índice? |
|---|---|---|
| Igual a | Name = 'Plumbing Basics' | Sí |
| Empieza por | Name LIKE 'Plumbing%' | Sí |
| Uno de una lista corta | Id IN ('a01…', 'a02…', 'a03…') | Sí |
| Un rango de fechas o números | CreatedDate = THIS_YEAR, Amount > 10000 | Sí |
| Contiene | Name LIKE '%Plumbing%' | No |
| Termina en | Name LIKE '%Basics' | No |
| Distinto de, no como, no en | Name != 'Plumbing Basics' | No |
| Vacío | Region__c = null, Name != '' | No, por defecto |
That’s not just my rule of thumb. Salesforce lists the cases where a custom index typically isn’t used, including “The filter operator is a negative operator such as NOT EQUAL TO (or !=), NOT CONTAINS, and NOT STARTS WITH” and “You’re comparing with an empty value (Name != ”)” (Working with Very Large SOQL Queries (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27). And: “Custom indexes are never used for the following operations: NOT EQUAL TO comparisons, null value comparisons (e.g., Name = ”), leading wildcard searches (e.g., Name LIKE ‘%Smith’)” (Developer Console Query Plan Tool FAQ (se abre en una pestaña nueva), Help, version 5). ⟲
Y si lo que de verdad necesitas es encontrar una palabra en cualquier parte del texto, recuerda las dos maneras de preguntar del módulo anterior: para eso están hechos FIND y el motor de búsqueda. El módulo 5 lo trata.
La palabra para esto: selectivo
Sección titulada «La palabra para esto: selectivo »Así que hay dos cosas que comprobar antes de que un índice pueda acelerar tu consulta. Una: ¿hay un índice en el campo? Dos: ¿pides los datos de una manera que el índice pueda usar? Igual a, empieza por, una lista corta, un rango de fechas o números: sí. Contiene, termina en, distinto de, vacío: no.
Cuando preguntas de la segunda manera, digo que preguntas de forma selectiva. Esa es la palabra que hay que aprender: selectivo. Un filtro selectivo es uno que Salesforce puede responder a través de un índice en lugar de recorrer todos los registros. A los informes, las vistas de lista y SOQL les importa.
Salesforce’s own definition has one more part, and it’s the reason this module isn’t over yet: “A query is selective when one of the query filters is on an indexed field and the query filter reduces the resulting number of rows below a system-defined threshold” (Working with Very Large SOQL Queries (se abre en una pestaña nueva), Winter ‘27). An index, asked the right way, and not too many records. That’s the second of the three, the pedal all the way down. The third check, the engine in the right range, is where people get into trouble, and it comes next. ⟲
Conocimiento para el examen. Un filtro solo puede usar un índice si el campo está indexado y preguntas de forma selectiva. Selectivo: igual a, empieza por (
LIKE 'abc%'), una listaINcorta, un rango de una fecha o un número. No selectivo: contiene y termina en (un%inicial), los operadores negativos (!=,NOT LIKE,NOT IN) y las comparaciones con un valor vacío.
Una nota sobre los campos cifrados. Si un campo está cifrado con Shield Platform Encryption, compruébalo antes de construir un filtro importante sobre él. Las propias páginas Well-Architected de Salesforce no coinciden hoy. Trust (se abre en una pestaña nueva) dice que el cifrado probabilístico no se puede usar para filtrar, ordenar ni agregar, y que el cifrado determinista permite filtros de coincidencia exacta. Data Protection Patterns (se abre en una pestaña nueva) dice que el cifrado probabilístico “admite todas las operaciones de consulta”. Lee las dos (consultadas el 2026-10-21) y prueba el filtro en tu propia organización.
Todo el mundo vive en Arizona: cuando un índice no ayuda
Sección titulada «Todo el mundo vive en Arizona: cuando un índice no ayuda »Así que tienes un índice y lo preguntas de la manera correcta: igual a, nada sofisticado. ¿Basta con eso? No siempre. Este es el ejemplo que uso en clase.
Supongamos que tenemos las direcciones de 10 millones de personas de todo Estados Unidos, y el campo del estado está indexado. Pide a todos los de Arizona: State = 'AZ'. Arizona es una pequeña parte de todo el país, así que el índice reduce 10 millones de registros a un grupo pequeño. Ve al cajón, saca las fichas de Arizona, trae esos registros. Rápido. Eso es el índice haciendo su trabajo.
Ahora cambia los datos, no la consulta. El mismo campo, el mismo índice, el mismo State = 'AZ'. Pero esta vez todo el mundo vive en Arizona. Coinciden los 10 millones de registros. El índice no acota nada. Ir primero al índice y luego traer 10 millones de registros ficha a ficha es en realidad más lento que leer la tabla entera. El índice no está roto. Simplemente no es útil para esta pregunta.
Y esta es la clave: depende de lo que estés buscando. Quédate con los datos de todo Arizona y añade una persona en Texas. Pide State = 'TX': una coincidencia. El índice te lleva directamente a ese único registro. Rápido. Pide State = 'AZ' sobre los mismos datos: coincide casi todo. Lento. El mismo campo, el mismo índice, los mismos datos. La única diferencia es cuántos registros coinciden con lo que pediste. Cuando un gran número de registros coincide con lo que buscas, el índice deja de ayudar.
Vigila esto con campos como el estado de un caso. Status = 'Closed' puede ser un buen filtro al principio y dejar de serlo a medida que los casos cerrados se acumulan año tras año. Volveremos a ello en La trampa de los casos cerrados.
Personas de todo Estados Unidos: Arizona es una pequeña parte. Rápido.
Todo el mundo vive en Arizona: coinciden todas las fichas. Leer la tabla es más rápido. Lento.
Los mismos datos, una persona en Texas: una ficha. Rápido. Decide lo que estás buscando.
Por qué demasiadas coincidencias es más lento
Sección titulada «Por qué demasiadas coincidencias es más lento »Piensa otra vez en la biblioteca. Quieres un libro: encuentra la ficha, ve a la estantería, listo. Ahora quieres 9 millones de los 10 millones de libros, e insistes en usar el catálogo de fichas. Encuentra una ficha, ve a la estantería, vuelve al cajón, siguiente ficha, ve a otra estantería, vuelve… nueve millones de veces. Sería más rápido empezar por el primer pasillo y recorrer las estanterías una sola vez, en orden.
Salesforce incorpora ese límite al propio índice: “La tabla de índice impone límites superiores al número de registros que una búsqueda indexada puede devolver de forma eficaz” (Indexes (se abre en una pestaña nueva), Winter ‘27). Así que antes de usar un índice, Salesforce cuenta: ¿cuántos registros coincidirían con este filtro? Si la respuesta es una parte pequeña del objeto, el índice compensa. Si las coincidencias superan cierto porcentaje de los registros, Salesforce se salta el índice y lee la tabla.
Ese porcentaje tiene nombre: el umbral de selectividad. Recuerda la definición de Salesforce de una consulta selectiva: un campo indexado, preguntado de la manera correcta, y un filtro que “reduce el número de filas resultante por debajo de un umbral definido por el sistema”. Este es ese umbral, y es la tercera comprobación. Veamos las cifras.
Los umbrales
Sección titulada «Los umbrales »¿Por qué importa tanto el umbral? La guía Well-Architected de Salesforce no lo suaviza: “La selectividad de las consultas es la mayor palanca individual para que una solución escale a millones de registros o agote el tiempo de espera con cientos de miles.” Y: “La selectividad es capacidad que no tienes que comprar” (Resource and Cost Optimization (se abre en una pestaña nueva)). Una consulta eficiente deja sitio a todos los demás inquilinos del edificio.
Salesforce fija la línea como un porcentaje de los registros, y el porcentaje depende del tipo de índice: una regla para un índice estándar, una más baja para un índice personalizado (Make Salesforce Platform SOQL Query Selective (se abre en una pestaña nueva), Help, versión 4). Empecemos por el caso sencillo y vayamos construyendo.
Empezar por lo sencillo: un índice estándar
Sección titulada «Empezar por lo sencillo: un índice estándar »Toma el campo Name. Tiene un índice estándar. Supongamos que tenemos 100.000 cuentas. Para un índice estándar, la línea es el 30 % de los registros: 30.000.
Ahora pide Name LIKE 'Steve%'. Steve’s Plumbing, Steve’s Garage, unas cuantas más: pongamos 2.000 cuentas. 2.000 está por debajo de 30.000, así que el filtro es selectivo y Salesforce usa el índice. Rápido.
El mismo campo, el mismo índice, las mismas 100.000 cuentas. Ahora pide Name LIKE 'S%', todas las cuentas que empiezan por S. Pongamos que son 40.000. 40.000 está por encima de la línea. No es selectivo: Salesforce se salta el índice y lee la tabla.
El mismo índice, los mismos registros. Por debajo de la línea, se usa el índice. Por encima, no.
Los dos filtros preguntan de forma selectiva, con un “empieza por”. Los dos usan un campo indexado. La única diferencia es cuántos registros coinciden.
A medida que crece el objeto
Sección titulada «A medida que crece el objeto »Entonces, ¿la línea es el 30%? Para el primer millón de registros, sí. A partir de ahí, Salesforce cuenta solo el 15 % de los registros que pasan del primer millón, y la línea nunca supera 1 millón. En palabras de Salesforce, el umbral estándar “llega a su máximo en 1 millón de registros objetivo en total, que solo podrías alcanzar si tuvieras más de 5,6 millones de registros en total” (misma fuente).
- 500.000 registros: el 30 % de ellos, 150.000.
- 1 millón de registros: el 30 % de ellos, 300.000.
- 2 millones de registros: 300.000 por el primer millón, más el 15 % del segundo millón (150.000): 450.000.
- 6 millones de registros: la cuenta daría 1.050.000, pero el tope es 1 millón. Ese es el máximo.
La línea crece con el objeto, más despacio después del primer millón, y se detiene en 1 millón.
Mira lo que le pasa a la proporción. Con 1 millón de registros, un filtro puede coincidir con el 30 % y seguir siendo selectivo. Con 2 millones, el 22,5 %. Con 6 millones, menos del 17 %. Cuanto más grande es el objeto, más tiene que acotarlo un filtro. La guía Well-Architected de Salesforce lo dice del mismo modo: los umbrales “se endurecen a medida que un objeto supera su primer millón de registros” (Resource and Cost Optimization (se abre en una pestaña nueva)).
Índices personalizados: una línea más baja
Sección titulada «Índices personalizados: una línea más baja »Ahora un índice personalizado. Volvamos a State = 'AZ': State no es un índice estándar, así que necesita uno personalizado. Un índice personalizado tiene una línea más baja: el 10 % del primer millón de registros, más el 5 % de los registros a partir de ahí, nunca más de 333.333 (misma fuente).
- 100.000 registros: el 10 % de ellos, 10.000.
- 1 millón de registros: el 10 % de ellos, 100.000.
- 6 millones de registros: la cuenta daría 350.000, pero el tope es 333.333. El máximo.
Un índice personalizado: un tercio de la línea estándar y un tope de 333.333.
Así que con un millón de contactos, State = 'AZ' solo es selectivo si menos de 100.000 de ellos viven en Arizona. Y con 10 millones de contactos, la línea sigue siendo 333.333, alrededor del 3,3 %. Esa es la parte que la gente olvida: llega un momento en que los umbrales dejan de crecer. Por eso el diseño para grandes volúmenes no es “ponle un índice”. La pregunta es ¿cómo será la distribución a escala?
Conocimiento para el examen. Conoce los dos umbrales. Índice estándar: el 30 % del primer millón de registros, más el 15 % del resto, hasta 1 millón. Índice personalizado: el 10 % del primer millón, más el 5 % del resto, hasta 333.333. Prepárate para calcular uno: un índice estándar con 2 millones de registros permite 450.000; un índice personalizado con 1 millón permite 100.000.
La trampa de los casos cerrados
Sección titulada «La trampa de los casos cerrados »Uno de mis ejemplos favoritos, porque la consulta funciona perfectamente en el lanzamiento. Un filtro sobre IsClosed = true. Al principio: 100.000 casos, 20.000 cerrados. Estupendo. Pasa el tiempo, y los casos tienen una costumbre interesante: se cierran. Ahora hay 10 millones de casos, 9 millones cerrados. No cambió nada de la consulta, el campo ni el código. Cambió la distribución. El filtro que antes acotaba la población ahora describe casi toda. Pasó de selectivo a no selectivo porque los datos envejecieron. Una consulta puede volverse mala sin que la consulta cambie.
Añade un 30 % de crecimiento
Sección titulada «Añade un 30 % de crecimiento »Así que combino la selectividad con el Número de Ceros y el crecimiento. Si el cliente no tiene una proyección, uso un 30 % anual como base de planificación, no porque todos los negocios crezcan un 30 %, sino porque nos da algo contra lo que diseñar en lugar de fingir que el volumen de hoy es permanente. Empieza con 1,5 millones de registros: 1,95 millones el segundo año, 2,54 el tercero, 3,30 el cuarto, 4,28 el quinto, 5,57 el sexto. Con unos 5,6 millones de registros, el umbral personalizado sin máximo es 100.000 más el 5 % de 4,6 millones, 330.000: prácticamente el máximo de 333.333. A partir de ahí los datos siguen creciendo y el umbral personalizado, en la práctica, no. Haz esas cuentas antes de que te las enseñe producción.
El filtro selectivo de hoy puede convertirse en el problema de producción de mañana.
Dos 30 % distintos. No confundas este 30 % con otro 30 % que encontrarás en la guía Well-Architected de Salesforce. Reliability (se abre en una pestaña nueva) dice: “Crea margen fijando el 70 % de los límites del regulador como techo operativo en condiciones normales, y reserva el 30 % para picos inesperados.” Ese 30 % es margen de reserva bajo los límites del regulador de una transacción. El 30 % de aquí es la rapidez con que crecen los datos cada año. Cifras distintas para cosas distintas. Y fíjate en cómo describe Salesforce la cifra del 70 % en otra página: “una buena práctica de la comunidad muy citada, no una especificación oficial de Salesforce” (The Agentic Enterprise (se abre en una pestaña nueva)). Tómala como un buen consejo, no como una regla (páginas consultadas el 2026-10-22). Y recuerda: cuando tus registros principales crecen un 30 %, los registros que dependen de ellos pueden crecer más rápido. Cada cuenta nueva trae pedidos, cada pedido trae partidas, y todos ellos traen actividades e historial. Los objetos hijos y los datos transaccionales pueden multiplicar el crecimiento, y no siempre puedes saber cuál crecerá primero hacia un límite de Salesforce, o lo superará. Así que haz las cuentas para los hijos, no solo para los padres.
Steve Trucking: la consulta de hoy, cinco años después
Sección titulada «Steve Trucking: la consulta de hoy, cinco años después »Lanzamiento con un millón de entregas; los coordinadores filtran a menudo por Status = 'Scheduled', unos 100.000 registros, el 10 %. Razonable. Cinco años después hay unos 9 millones de órdenes de trabajo acumuladas, pero el número de programadas en cada momento lo marca la ventana operativa, así que se mantiene pequeño. Ese filtro puede volverse incluso más selectivo a medida que crece el historial. Ahora Status = 'Completed': los registros completados se acumulan año tras año, y ese filtro cada vez acota peor. El mismo campo, el mismo índice, otro valor, otra distribución, otro comportamiento. Eso es la selectividad.
Más allá del examen: lo que cambia la IA. Un asistente de IA escribe
WHERE Status = 'Completed'con la misma facilidad que un desarrollador, y funciona en una org de pruebas. Producción sigue teniendo el mismo optimizador, los mismos índices, umbrales y distribución. La IA no deroga la física de las bases de datos. Prueba las consultas generadas por IA con un volumen y una distribución realistas, no con 500 casos de ejemplo.
Las tres: el impulso
Sección titulada «Las tres: el impulso »Volvamos a la carrera. Tienen que cumplirse tres cosas para que se dispare el nitro, y ahora conoces las tres para una consulta:
- Hay un índice en el campo por el que filtras. (El nitro está instalado.)
- Preguntas de forma selectiva: igual a, empieza por, una lista corta, un rango de fechas o números. (El pedal está pisado a fondo.)
- No coinciden demasiados registros: estás por debajo del umbral de ese índice, hoy y a medida que crecen los datos. (El motor está en el rango adecuado.)
Las tres, y Salesforce va al índice y tu consulta sale disparada. Falla una sola, y Salesforce lee la tabla: simplemente vas conduciendo. Y fíjate en que la tercera puede cambiar por sí sola. Los casos cerrados se acumulan, el objeto crece, y una consulta que tenía el impulso el año pasado no lo tiene este año.
Entonces, ¿quién comprueba las tres cada vez que se ejecuta una consulta? Ni tú ni el desarrollador. Ese es el trabajo del bibliotecario, y es el próximo módulo.
Conocimiento para el examen. Para que se use un índice, tienen que cumplirse tres cosas: el campo está indexado, el filtro es selectivo en su forma de preguntar (sin comodín inicial, sin operador negativo, sin comparación con un valor vacío) y el número de registros que coinciden está por debajo del umbral de selectividad.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué filtros de gran volumen deben seguir siendo selectivos hoy, y en el tercer año, el quinto y después.
- Si los campos que usan esos filtros tienen un índice, estándar o personalizado, y si compensa su coste.
- Si los filtros preguntan de forma selectiva, o dependen de contiene, termina en, distinto de o valores vacíos.
- Si la distribución real de los valores, no solo la existencia de un índice, mantiene cada filtro por debajo de su umbral a medida que crecen los datos.
- Qué consultas, incluidas las generadas por IA, hay que probar con un volumen y una distribución realistas antes de producción.
Sí, sábete los umbrales: estándar, el 30 % del primer millón más el 15 % del resto, con un máximo de 1 millón; personalizado, el 10 % más el 5 %, con un máximo de 333.333. Pero si eso es todo lo que aprendes, te perdiste la lección. El fichero de tarjetas solo es útil cuando ahorra suficiente trabajo; un filtro indexado que lo devuelve casi todo no es un atajo; y el mismo filtro puede pasar de selectivo a no selectivo a medida que los datos crecen y envejecen. Así que, cuando alguien diga “tranquilo, ese campo está indexado”, haz las tres preguntas. Luego haz las cuentas.
Explora
Sección titulada «Explora »- Salesforce Developers, Apex Developer Guide (Winter ‘27), Working with Very Large SOQL Queries (se abre en una pestaña nueva), checked 2026-11-01: what makes a query selective, and when a custom index typically isn’t used. ⟲
- Salesforce Help, Make Salesforce Platform SOQL Query Selective (se abre en una pestaña nueva) (version 4, April 2026: the thresholds and their caps) and Developer Console Query Plan Tool FAQ (se abre en una pestaña nueva) (version 5, June 2026), checked 2026-11-01. ⟲
- Salesforce Architects, Well-Architected, Resource and Cost Optimization (se abre en una pestaña nueva), checked 2026-11-01: Query Selectivity. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27), Indexes (se abre en una pestaña nueva), checked 2026-11-01: the index table places upper limits on how many records an indexed search can return. ⟲
- Salesforce Architects, Well-Architected, Trust (se abre en una pestaña nueva) and Data Protection Patterns (se abre en una pestaña nueva), checked 2026-11-01: filtering on encrypted fields (the two pages differ). ⟲
- Salesforce Architects, Well-Architected, Reliability (se abre en una pestaña nueva) and The Agentic Enterprise (se abre en una pestaña nueva), checked 2026-11-01: the 70% governor-limit ceiling and its 30% reserve, and how Salesforce describes it. ⟲