Buscar no es consultar

🌐 También en 19 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Français (Canada) · Deutsch (Schweiz)

Imagen generada con IA

Traducido con IA. Aún no revisado por la comunidad. Leer en inglés Esta sección cambió en inglés y aún no se ha vuelto a traducir. (11)

Módulo 5 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 ejecuta Salesforce una consulta · Siguiente: el próximo capítulo, Integración y movimiento de datos

La pregunta que responde este módulo: ¿cuándo deberías buscar en lugar de consultar?

Tres módulos sobre consultas, índices, selectividad, planes de consulta y skinny tables dan todos por sentada una cosa: sabes lo que estás buscando. Las entregas de hoy de Redrock. Los casos modificados desde ayer. La entrega con la referencia de socio DLV-8472914. Preguntas estructuradas. Pero la gente no siempre hace preguntas estructuradas. A veces dice: “Recuerdo que el cliente mencionó una nevera dañada en Tempe. ¿Puedes encontrarlo?”. Eso no es realmente un problema de consulta. Es búsqueda. Y buscar no es consultar.

La consulta empieza por la estructura; la búsqueda, por un término

SOQL es fantástico cuando conocemos la estructura: el objeto, el campo, la condición. Órdenes de trabajo cuyo socio minorista es Redrock y cuya fecha programada es hoy. Sabemos dónde vive la información, cómo se representa y qué estamos comprobando, y la base de datos puede usar todo lo que hemos diseñado en este capítulo.

Ahora: “encuentra el registro con la frase nevera rota”. ¿Qué objeto? ¿Un caso, una orden de trabajo, una nota? ¿El asunto, la descripción, otro campo de texto? El usuario no lo sabe, y no debería tener que saberlo. Ahí entra SOSL, el Salesforce Object Search Language. En lugar de “¿qué campo debería filtrar?”, empieza por “encuentra este texto”. Un problema de recuperación fundamentalmente distinto.

He visto a desarrolladores forzar la búsqueda dentro de SOQL. “Que el usuario escriba un texto y encontremos al cliente”, y la consulta crece: Name LIKE … OR Email LIKE … OR Phone LIKE … OR Description LIKE … OR otro campo, y otro. En algún momento, para y pregunta: ¿estamos consultando o buscando? Si el requisito es descubrir texto en varios campos, SOSL puede ser la herramienta más limpia. Para eso está. No metas un problema de búsqueda en la forma de una consulta porque SOQL sea la herramienta que más usas.

Recuerda el caso más difícil del módulo 3: contiene. Description LIKE '%refrigerator%' no tiene forma de entrar en el cajón, así que el bibliotecario recorre todas las estanterías. La búsqueda se hizo exactamente para esa pregunta. Salesforce lo dice directamente: “Cuando una búsqueda puede usar cualquiera de los dos lenguajes, SOSL suele ser más rápido que SOQL si la expresión de búsqueda usa un término CONTAINS”, porque “SOSL puede dividir en tokens varios términos dentro de un campo (por ejemplo, varias palabras separadas por espacios) y construye un índice de búsqueda a partir de ello”. Buscar “John” en “Paul and John Company” es una pregunta de búsqueda (Using SOQL and SOSL (se abre en una pestaña nueva), Best Practices for Deployments with Large Data Volumes, Winter ‘27).

Clic para ampliar

“Contiene” forzado en una consulta: sin forma de entrar en un índice. Lento.

Clic para ampliar

Las mismas palabras, preguntadas como búsqueda: directo a las coincidencias. La consulta conoce la estructura. La búsqueda conoce el término.

Cómo funciona la búsqueda: primero los tokens, luego la recuperación

Volvamos a la biblioteca. Un índice de base de datos es el catálogo para “los libros de este autor” o “los libros con este identificador”. Ahora quiero todos los libros que contienen la frase “frigorífico estropeado”. Leer cada página de cada libro en cada búsqueda sería absurdo, así que la búsqueda construye su propio índice sobre las palabras. “La arquitectura de búsqueda de Salesforce se basa en su propio almacén de datos, optimizado para buscar ese texto” (Search Architecture (se abre en una pestaña nueva), Winter ‘27): un motor distinto para un tipo de pregunta distinto.

¿Cómo llena ese almacén? “Cuando creas un registro, el motor de búsqueda divide el contenido que se puede buscar en piezas más pequeñas, llamadas tokens. Guarda los tokens en un índice de búsqueda. El índice de búsqueda se parece mucho al índice de un libro: cada token del índice tiene un enlace de vuelta al registro del que procede” (How Einstein Search Works (se abre en una pestaña nueva), Salesforce Help). Cuando buscas, tus palabras se dividen en tokens de la misma manera y se comparan con ese índice.

Y luego viene un paso que la gente pasa por alto. “Salesforce realiza las búsquedas indexadas buscando primero en los índices los registros adecuados y luego acotando los resultados según los permisos de acceso, los límites de búsqueda y otros filtros … El conjunto de resultados se usa después para consultar los registros en la base de datos y obtener los campos que ve el usuario” (Search Architecture (se abre en una pestaña nueva)). Con las cuatro palabras del módulo 4: la búsqueda encuentra qué registros en su propio índice, y luego una recuperación normal de la base de datos trae sus campos. Dos motores, uno detrás del otro.

Y no es solo el cuadro de búsqueda. Salesforce enumera la búsqueda detrás de “las búsquedas avanzadas y globales”, “los cuadros de búsqueda y los campos de búsqueda”, “las soluciones sugeridas y la base de conocimientos”, “Web-to-Lead y Web-to-Case”, “el procesamiento de prospectos duplicados” y SOSL desde Apex y la API (misma fuente). Como el bibliotecario, la búsqueda trabaja en lugares que nadie considera “búsqueda”.

La frescura forma parte del diseño

Ese índice es asíncrono. Los registros nuevos y modificados se ponen en cola y los indexan servidores separados, y “podrían pasar unos 15 minutos o más hasta que el texto actualizado se pueda buscar” (Search Architecture (se abre en una pestaña nueva)). Las cargas grandes tardan más: “Si un registro se crea o se actualiza con Bulk API, puede tardar más de 15 minutos en poder buscarse … espera unas horas a que se indexe” (How Einstein Search Works (se abre en una pestaña nueva)). Así que después de una migración, el índice de búsqueda va retrasado durante un tiempo, igual que el cuaderno de estadísticas del módulo 4 va retrasado hasta la ejecución nocturna.

Así que la búsqueda y la consulta tienen una frescura distinta. Steve Trucking crea un caso a las 10:00; a las 10:01 una consulta SOQL lo devuelve, mientras que una búsqueda de texto de las palabras de su descripción depende de si el índice de búsqueda se ha puesto al día. Eso no es un defecto. Es una propiedad del mecanismo. “En el momento en que se crea una incidencia de entrega, nuestra automatización tiene que encontrarla.” ¿Construiría eso sobre la búsqueda de texto? No. El proceso conoce la orden de trabajo, el tipo de incidencia, la fecha y el estado, así que una consulta estructurada es la opción determinista. “¿Un agente de atención quiere casos antiguos en los que los clientes mencionaron frigoríficos dañados?” La búsqueda tiene mucho más sentido. Requisito distinto, motor distinto, frescura distinta. Elige el mecanismo de recuperación a partir de la pregunta, no de la costumbre.

La búsqueda cruza objetos, y puede encontrar demasiado

Uno de los puntos fuertes de SOSL es que el usuario no necesita saber qué objeto contiene la respuesta. Un coordinador busca “Henderson”, y puede ser una cuenta, un contacto, una orden de trabajo o un caso. El usuario busca la cosa, no piensa “primero consulto Contact.LastName, luego Account.Name, luego el destinatario de la orden de trabajo, luego las descripciones de los casos”. La búsqueda encaja con la forma en que la gente busca de verdad la información.

Eso crea otro problema. Haz que todo se pueda buscar (cada objeto, campo, registro histórico, cada trozo de texto), busca luego “Smith”, y el usuario se ve desbordado. La búsqueda no falló; encontró demasiado. Eso es la saturación de la búsqueda (search crowding), y a escala importa tanto como la velocidad.

La saturación de la búsqueda, paso a paso

Salesforce la define claramente: “La saturación de la búsqueda (tener demasiados resultados de búsqueda poco útiles) puede desbordarte con registros irrelevantes y ralentizar la búsqueda. Para evitar la saturación de la búsqueda, el motor de búsqueda limita el número de registros que analiza” (How Search Crowding Affects Search Results (se abre en una pestaña nueva), Salesforce Help). El límite está ahí para proteger la búsqueda. El coste es que el registro que querías puede quedar fuera de él.

Recorramos una búsqueda. Una agente de atención de Steve Trucking busca un caso sobre un frigorífico dañado de un cliente llamado Henderson. Escribe Henderson en la búsqueda global. Henderson también es una ciudad, así que la palabra aparece en miles de direcciones de entrega. El propio ejemplo de Salesforce usa estas cifras, así que usémoslas también:

1. Todos los registros que coinciden. El índice de búsqueda encuentra 3.200 registros con la palabra Henderson: cuentas, contactos, casos y muchísimas órdenes de trabajo.
2. El límite. “La búsqueda limita los resultados a los primeros 2.000 registros encontrados, así que 1.200 registros no se incluyen en tus resultados de búsqueda” (misma fuente). Si su caso está entre esos 1.200, ha desaparecido antes de que ocurra nada más.
3. Permisos. Solo ahora comprueba la búsqueda lo que ella puede ver. “La búsqueda analiza solo 2.000 registros, que pueden incluir registros a los que no tienes acceso. De los 2.000 analizados, no tienes acceso a 100, así que no los ves en tus resultados. Solo ves 1.900 registros devueltos” (misma fuente). Esos 100 ocuparon igualmente sitio en los 2.000. Vuelve a leerlo: el corte llega antes que el uso compartido, así que registros que ella nunca verá pueden ocupar plazas en los 2.000 y empujar el registro que necesita más allá de la línea.
4. Repartidos entre objetos. Cuando una búsqueda nombra varios objetos, los 2.000 se reparten. En palabras de Salesforce: “Si consultas un solo objeto, se devuelve un máximo de 250 registros. Para devolver hasta 2.000 resultados, incluye la cláusula WHERE o la cláusula ORDER BY. Si consultas varios objetos, cada objeto devuelve hasta el mínimo entre 2.000/n (donde n = número de objetos) y 250.” Busca en diez objetos a la vez y cada uno obtiene como mucho 200. Y los resultados no son los mismos para todos: “Los administradores (usuarios con el permiso Ver todos los datos) ven el conjunto completo de resultados devueltos”, mientras que los demás usuarios solo ven aquello a lo que tienen acceso, y “Los conjuntos de resultados y su orden varían según el usuario que hace la búsqueda y pueden cambiar a lo largo del día a medida que se añaden o eliminan registros del índice” (misma fuente). El orden también varía: Salesforce ordena los resultados “según la frecuencia del término de búsqueda, el orden, la singularidad, la actividad del registro y los permisos de acceso. La relevancia de los resultados de búsqueda puede variar para cada usuario” (How Einstein Search Works (se abre en una pestaña nueva)). Así que cuando alguien dice “lo busqué y no estaba”, las primeras preguntas son: ¿cuántos registros coincidieron antes del límite, y quién eras?
5. Ordenados. Lo que queda se ordena por relevancia, así que incluso cuando su caso sobrevive, puede estar muy abajo en la lista, bajo otros 1.900 Henderson.

Clic para ampliar

Primero llega el corte, después el uso compartido. Registros que ella no puede ver ocupan plazas en los 2.000, y su caso acaba en el cubo de descartes.

Ahora llevémoslo al peor caso que permite el mecanismo. Un objeto tiene 100.000 registros, y el uso compartido permite a esta usuaria ver 1.000 de ellos. Busca 10 registros concretos, y puede ver los 10. Su término de búsqueda coincide con 3.000 registros. Los primeros 2.000 encontrados son todos registros que no puede ver; sus 10 están entre los 1.000 que quedan pasado el corte, en el cubo de descartes. El uso compartido quita los 2.000 que se conservaron, y no obtiene ningún resultado, para registros que sabe que existen y que tiene permiso para ver.

Clic para ampliar

Visibles para ella, y aun así no encontrados: las 2.000 plazas fueron para registros que no puede ver.

Para ser justos con Salesforce, esto es el extremo, no lo cotidiano. El mismo artículo de ayuda dice: “La prioridad del motor de búsqueda es devolver registros accesibles para los usuarios con acceso limitado en una organización” (How Search Crowding Affects Search Results (se abre en una pestaña nueva)), y la relevancia tiene en cuenta el acceso. La mayoría de las veces eso mantiene a los usuarios con acceso limitado fuera de esta trampa. Pero cuando alguien con acceso limitado asegura que falta un registro en la búsqueda y luego lo encuentra abriendo una vista de lista, esta es la razón, y la solución es la misma: una búsqueda más específica, menos objetos, menos registros que compitan.

Esa es la esencia. “El motor de búsqueda busca coincidencias con el término de búsqueda en un máximo de 2.000 registros”, y solo entonces aplica los permisos de cada usuario, así que el usuario solo ve lo que tiene permitido (SOSL Limits on Search Results (se abre en una pestaña nueva), SOQL and SOSL Reference). Así que 2.000 coincidencias irrelevantes, incluidos registros que este usuario ni siquiera puede ver, pueden desplazar el que quería antes de que el uso compartido recorte la lista. La pregunta no es solo “¿qué rapidez tiene la búsqueda?”. Es ¿diseñamos la búsqueda para que pueda aparecer la respuesta útil?

Así que cuando alguien dice “lo busqué y no estaba”, las primeras preguntas son: ¿cuántos registros coincidieron antes del límite, en cuántos objetos se buscó y quién estaba buscando?

Reducir la saturación de la búsqueda: un plan de acción

La solución siempre es la misma idea: menos coincidencias, y mejores, antes del límite. Este es el plan de acción que le daría a un administrador y a un arquitecto cuando alguien dice “lo busqué y no estaba”. Síguelo en orden.

Clic para ampliar

Descarta primero la frescura, el acceso y la posibilidad de búsqueda. Luego mide.

Paso 1: descarta las otras causas

No todo registro que falta es saturación. Comprueba primero las causas sencillas:

• ¿Es demasiado nuevo? El texto puede tardar unos minutos en indexarse, y “Si un registro se crea o se actualiza con Bulk API, puede tardar más de 15 minutos en poder buscarse … espera unas horas” (How Einstein Search Works (se abre en una pestaña nueva)). Un registro cargado esta mañana puede que aún no se pueda buscar.
• ¿Puede verlo este usuario? Ábrelo desde una vista de lista o un informe como ese usuario. Si no puede, es el acceso, no la búsqueda. “Los administradores también pueden comprobar la configuración de perfiles y permisos para el acceso a los objetos” (How Search Crowding Affects Search Results (se abre en una pestaña nueva)).
• ¿Se puede buscar en el objeto? “Por defecto, la búsqueda está desactivada en los objetos personalizados nuevos. Los administradores activan Allow Search al configurar los objetos personalizados nuevos” (aunque “Un objeto personalizado asociado a una ficha personalizada se puede buscar por defecto”) (Searchable Fields: Custom Object (se abre en una pestaña nueva)). Y recuerda la regla de los 120 días: un objeto personalizado en el que no se busca puede perder la posibilidad de búsqueda.
• ¿Lo encuentra un término exacto y único? Busca algo que solo tenga ese registro, como su nombre completo o su número de referencia. Si eso funciona y el término amplio no, estás ante una saturación.

Paso 2: mide la saturación

Vuelve a buscar el término amplio y luego búscalo objeto por objeto. Si una búsqueda vuelve en el límite, 2.000 en total o 250 para un solo objeto sin WHERE ni ORDER BY, los resultados se cortaron. Anota qué objeto aporta la mayoría de las coincidencias. En el ejemplo de Henderson, son las órdenes de trabajo, cuyas direcciones de entrega están llenas de esa palabra.

Paso 3: reduce el ruido en el origen

Unos datos pueden merecer existir sin merecer aparecer en la búsqueda. Estos son cambios de configuración, hechos en Search Manager (“Para usar Search Manager: Customize Application Y View Setup”). Hazlos en este orden, del más barato al más estructural:

1. Desactiva por perfil los objetos en los que estos usuarios no buscan. “Puedes gestionar los objetos que se pueden buscar para cada perfil en la búsqueda global.” Desde Configuración, entra en Search Manager, selecciona Query Configurations, selecciona la configuración y “en la lista de objetos, selecciona un objeto y activa o desactiva la posibilidad de búsqueda” (Manage Searchable Objects and Fields (se abre en una pestaña nueva)). Si los agentes de atención nunca buscan partidas de orden de trabajo, su perfil no debería buscarlas.
2. Saca del índice los campos personalizados ruidosos. Desde Configuración, entra en Search Manager, selecciona Index Management, elige el objeto y, junto al campo, elige Remove from search index. “Los campos eliminados no aparecen en los resultados de búsqueda y no se usan para encontrar coincidencias. No puedes eliminar campos estándar”, y “Tus cambios pueden tardar unas horas” (Manage the Search Index (se abre en una pestaña nueva)). Un campo largo de descripción o de dirección que coincide con todo es un buen candidato.
3. Para un objeto en el que nadie debería buscar, desactiva su índice de búsqueda. Eso deja de “hacer que sus datos se puedan buscar y detiene el consumo de créditos de índice para ese objeto” (Explore the Search Index with Search Manager (se abre en una pestaña nueva)).
4. Archiva el historial que ya no hace falta encontrar. Las órdenes de trabajo completadas antiguas se quedan en el índice y siguen compitiendo. El archivado (capítulo 7 y el cierre del módulo 4) reduce la saturación para la búsqueda y para las consultas.
5. Pon los identificadores donde la búsqueda mira primero. Una búsqueda en un campo de búsqueda solo busca en el nombre del registro, y un grupo de búsqueda NAME solo en los campos de nombre. Si la gente encuentra una entrega por la referencia del socio, asegúrate de que ese valor vive en un campo que la búsqueda trata como nombre o identificador.

Paso 4: arregla las búsquedas que construyes

Para cada búsqueda personalizada, en Apex, en un componente o en la herramienta de un agente:

• Devuelve solo los objetos que necesita la pregunta, cada uno con un WHERE: “En SOSL, los filtros selectivos reducen el número de resultados irrelevantes” (SOQL and SOSL (se abre en una pestaña nueva), buenas prácticas, Winter ‘27).
• Usa un grupo de búsqueda: IN NAME FIELDS, EMAIL o PHONE, para que un campo de dirección lleno de “Henderson” no coincida con una búsqueda por nombre.
• Prefiere los términos específicos a los comodines, y las búsquedas en un solo objeto “para ganar velocidad y precisión” (Searching (se abre en una pestaña nueva), buenas prácticas, Winter ‘27). La siguiente sección, Buscar bien, tiene los detalles.

Paso 5: enseña a quienes buscan

Incluye tres hábitos en la formación y en el texto de ayuda:

• Un término más específico: “Usa un término de búsqueda más específico, como Industrial Computing San Francisco” (How Search Crowding Affects Search Results (se abre en una pestaña nueva)). Para nuestra agente, Henderson refrigerator, o el nombre completo del cliente.
• Un solo tipo de registro: “si buscas un registro de cuenta, busca Industrial Computing en Cuentas” (misma fuente).
• El nombre completo en un campo de búsqueda: “Una búsqueda en un campo de búsqueda solo usa el nombre del registro”, así que “escribe Jupiter Hotels en lugar de solo Hotels” (misma fuente).

Clic para ampliar

La misma búsqueda, bien hecha: un término específico en un solo objeto, y su caso aparece.

Paso 6: verifica como ese usuario

Los cambios en el índice “pueden tardar unas horas”, así que compruébalo al día siguiente, no al minuto siguiente. Repite la búsqueda original como un usuario con ese perfil, no como administrador. Un administrador con Ver todos los datos ve resultados que otros usuarios no ven, así que la búsqueda de un administrador no demuestra nada sobre la saturación.

Paso 7: mantenlo sano

La posibilidad de búsqueda se desvía a medida que crece una organización, así que inclúyela en la revisión periódica:

• Cuando llega un objeto nuevo o un campo de texto grande, decide a propósito si se puede buscar, y para qué perfiles.
• Vigila la regla de los 120 días para los objetos personalizados en los que la gente busca rara vez.
• Mantén los campos sensibles fuera del índice. La búsqueda aplica la seguridad a nivel de campo solo a “hasta 100 campos personalizados que se pueden buscar por objeto” (Explore the Search Index with Search Manager (se abre en una pestaña nueva)), y el consejo de Salesforce es directo: “Si un campo contiene información sensible y no pudiste aplicarle seguridad a nivel de campo, elimina el campo del índice” (Manage the Search Index (se abre en una pestaña nueva)).

Clic para ampliar

Menos coincidencias, y mejores, antes del límite. Tres personas pueden conseguirlo.

Buscar bien

No necesitas escribir SOSL para ser arquitecto, pero deberías reconocer las palancas, porque son la forma de evitar que la respuesta correcta quede desplazada:

• Grupos de búsqueda. Busca solo en los tipos de campos que importan: “Los grupos de búsqueda incluyen los campos NAME, EMAIL y PHONE. Por ejemplo, FIND ‘Avery Smith’ IN NAME FIELDS RETURNING Account(Id,Name), Lead(Id,Name)” (misma fuente).
• RETURNING. Nombra los objetos y los campos que hay que traer, y añade un WHERE o un ORDER BY para superar el valor predeterminado de 250 registros de un solo objeto.
• Términos específicos. “Mantén las búsquedas específicas y evita usar comodines, si es posible. Por ejemplo, busca con Michael en lugar de Mi*.” Y “Usa búsquedas en un solo objeto para ganar velocidad y precisión” (Searching (se abre en una pestaña nueva), buenas prácticas, Winter ‘27).
• Comodines y operadores. Un asterisco coincide con “cero o más caracteres en el medio o al final de tu término de búsqueda”, y un signo de interrogación con exactamente uno. Las comillas mantienen una frase en orden, y AND, OR y AND NOT combinan términos (FIND {SearchQuery} (se abre en una pestaña nueva), SOQL and SOSL Reference). Fíjate: en el medio o al final. Como el índice del módulo 3, la búsqueda funciona mejor cuando sabe cómo empieza una palabra.
• Divisiones. SOSL se puede limitar a una división (WITH DivisionFilter), la herramienta de particionado del módulo 4.

And a few limits worth knowing. A transaction in Apex can run “Total number of SOSL queries issued: 20”, and “Total number of records retrieved by a single SOSL query: 2,000” (Execution Governors and Limits (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27). One quiet trap: “If SearchQuery is longer than 4,000 characters, any logical operators are removed. For example, the AND operator in a statement with a SearchQuery that’s 4,001 characters defaults to the OR operator, which could return more results than expected” (SOQL and SOSL Limits for Search Queries (se abre en una pestaña nueva)). ⟲

Conocimiento para el examen. Conoce los límites de SOSL: como máximo 2.000 registros buscados, y después se aplican los permisos; 250 para un solo objeto salvo que añadas WHERE u ORDER BY; hasta 2.000 divididos entre el número de objetos (y no más de 250 cada uno) cuando buscas en varios; 20 consultas SOSL por transacción de Apex. Conoce las palancas: los grupos de búsqueda (NAME, EMAIL, PHONE), RETURNING, los términos específicos frente a los comodines, y los comodines solo en el medio o al final.

La búsqueda se ejecuta como alguien

Search reaches across many objects and returns text, so who it runs as matters. In Apex, that changed recently. “Apex database operations, such as SOSL and SOQL queries, DML statements, and Database methods, now run in user mode by default. In user mode, database operations enforce the sharing rules, field-level security, and object permissions of the current user. In earlier API versions, database operations default to system mode” (Database Operations Run in User Mode by Default (se abre en una pestaña nueva), release notes, API version 67.0 and later). Code can still say which mode it wants: “To indicate an access mode for a SOQL or SOSL query, insert a WITH USER_MODE or WITH SYSTEM_MODE clause” (Set an Access Mode for Database Operations (se abre en una pestaña nueva), Apex Developer Guide). ⟲

Y como una pantalla de búsqueda acepta lo que escriba el usuario, es una puerta para la inyección. La guía Well-Architected de Salesforce la nombra: “Las inyecciones SOQL o SOSL se limitan a una lectura que revela registros o campos a los que quien llama no debería poder llegar, ampliando las condiciones de la consulta”, y pide “Validar y sanear toda entrada del usuario para evitar la inyección en los contextos SOQL, SOSL y HTML” (Trust (se abre en una pestaña nueva)).

La búsqueda en otros idiomas

Si tu organización trabaja en más de un idioma, la búsqueda no se comporta igual en todos. “La búsqueda está disponible para los idiomas totalmente compatibles. Sin embargo, no todas las funciones, incluidas la lematización y los grupos de sinónimos, están disponibles en todos los idiomas ni para todos los objetos. En los idiomas de usuario final solo se devuelven coincidencias exactas” (How Einstein Search Works (se abre en una pestaña nueva)). La lematización es lo que permite que una búsqueda de “entregas” encuentre “entrega”; sin ella, solo coincide la palabra exacta. Y para los idiomas que se escriben sin espacios, el motor usa la “tokenización morfológica” para encontrar las palabras, de modo que una búsqueda de Kioto (京都) no coincide con la prefectura de Tokio (東京都) (FIND {SearchQuery} (se abre en una pestaña nueva)). Para un equipo de atención global, prueba la búsqueda en cada idioma que la gente usa de verdad.

Busca para descubrir, consulta para operar

No es una cosa o la otra. El agente recuerda “nevera dañada Henderson”; la búsqueda encuentra el caso o la orden de trabajo; una vez que tienes su identidad, toma el relevo la recuperación estructurada. Busca para descubrir; consulta para operar.

Pero hay trampas en los dos lados. En cuanto la búsqueda funciona bien, los equipos se vuelven perezosos con la estructura: “no necesitamos modelar eso, la gente puede buscarlo”. No. Si la información mueve automatización, integración, seguridad, informes, reglas de negocio, emparejamiento o recuperación determinista, dale estructura. Si el socio minorista es una relación con significado, modélala; no entierres su nombre en una descripción con la esperanza de que la búsqueda lo encuentre. La búsqueda es estupenda para descubrir; no es un modelo de datos. Y al revés: si la gente necesita de verdad descubrir texto en varios campos y objetos, no la obligues a pasar por un laberinto de filtros estructurados porque eso sea más fácil para el equipo de desarrollo.

Un caso de estudio de la propia Salesforce muestra el patrón para una pantalla de búsqueda personalizada. Un cliente permitía a los usuarios buscar por cualquiera de 20 campos, con comodines, en varios objetos, y el rendimiento se resentía. Las soluciones: “Usar solo los campos de búsqueda esenciales”, “Desnormalizar los datos de varios objetos en un solo objeto personalizado” y “Determinar de forma dinámica el uso de SOQL o SOSL para realizar la búsqueda según el número de campos buscados y el tipo de valores introducidos. Por ejemplo, los valores muy específicos (es decir, sin comodines) usaban SOQL para la consulta, lo que permitía que los índices mejoraran el rendimiento” (Custom Search Functionality (se abre en una pestaña nueva)). Los valores exactos van al bibliotecario; las palabras van a la búsqueda.

La búsqueda vuelve a ser interesante

Durante años no he visto usar SOSL ni de lejos tanto como SOQL en los proyectos de Salesforce; el desarrollo transaccional empieza por registros estructurados y consultas estructuradas. La IA está volviendo a hacer interesante la arquitectura de búsqueda. Un agente no siempre empieza por WHERE Retail_Partner__c = 'Redrock'. Alguien pregunta: “¿qué clientes se han quejado de electrodomésticos dañados?” o “¿hay algo sobre problemas de entrega en la ubicación de Henderson?”. Ahora pasamos de la recuperación estructurada exacta a encontrar por palabras y, con el tiempo, por significado.

Y la búsqueda por palabras clave sigue sin ser búsqueda semántica. SOSL encuentra palabras. “Encontrar clientes descontentos porque las entregas no dejan de llegar tarde” puede coincidir con registros que dicen “ventana perdida”, “el conductor llegó después del cierre”, “tercera reprogramación” o “llegó dos días más tarde”, sin que ninguno use las palabras de la pregunta. Ahora estamos preguntando por el significado, lo que trae la recuperación semántica y, combinada con la estructura, la recuperación híbrida. El capítulo de grounding lo retoma en Choosing How the Agent Gets the Data (coming soon).

Los agentes también buscan. El servidor MCP alojado de Salesforce da a los agentes de IA una herramienta find junto a soqlQuery: “Ejecuta una búsqueda de texto en varios objetos de Salesforce a la vez … Devuelve un máximo de 2.000 registros en total. Usa grupos de búsqueda para acotar el alcance” (SObject All (se abre en una pestaña nueva), Hosted MCP Servers, consultado el 2026-10-22). Los mismos límites, la misma saturación, la misma necesidad de términos específicos, ahora preguntados por una máquina que no se cansa de preguntar.

Steve Trucking: ¿qué herramienta?

• “Dame las entregas de hoy de Redrock”. Objeto, socio, fecha: estructurado. SOQL.
• “Encuentra el registro en el que alguien mencionó muelle de carga dañado”. Palabras conocidas, campo u objeto desconocido: descubrir texto. SOSL.
• “Encuentra a los clientes que parecen frustrados por retrasos repetidos”. Significado parecido, palabras distintas: recuperación semántica.
• “Encuentra a los clientes frustrados de Redrock con entregas activas esta semana”. Significado más filtros estructurados: recuperación híbrida.

Lo que decide aquí un arquitecto

• Si un requisito es una recuperación estructurada, un descubrimiento de texto u otra cosa, en lugar de recurrir por defecto a SOQL; y si un “contiene” corresponde a la búsqueda.
• Qué objetos y contenidos merecen ser buscables, para que el ruido de gran volumen no desplace los resultados útiles.
• Si la frescura del índice de búsqueda es aceptable, incluso después de cargas masivas, o si el proceso necesita una recuperación estructurada determinista.
• Cómo afectan a la calidad de la búsqueda, con el volumen de producción, el límite de 2.000 registros, su reparto entre objetos y los permisos.
• Como quién se ejecuta la búsqueda, en el código y para los agentes, y cómo se protege de la inyección la entrada del usuario.
• Cómo se comporta la búsqueda en cada idioma que usa el negocio.
• Dónde la búsqueda debería descubrir registros y la consulta estructurada tomar el relevo.

Si piden órdenes de trabajo cuyo socio es Redrock y cuya fecha es hoy, es una pregunta estructurada: consulta. Si piden el registro en el que alguien escribió sobre una nevera rota, están buscando: búsqueda. No construyas diez OR porque SOQL te resulte familiar, y no busques en el universo entero porque activar la búsqueda en todas partes sea fácil. Buscar no es consultar. Y la siguiente pregunta se vuelve más fácil: ¿conozco la estructura, las palabras o el significado?

Explora

• Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27), checked 2026-11-01: Search Architecture (se abre en una pestaña nueva), Using SOQL and SOSL (se abre en una pestaña nueva), best practices for Searching (se abre en una pestaña nueva) and SOQL and SOSL (se abre en una pestaña nueva), and the Custom Search Functionality (se abre en una pestaña nueva) case study. ⟲
• Salesforce Developers, SOQL and SOSL Reference, SOSL Limits on Search Results (se abre en una pestaña nueva) and FIND {SearchQuery} (se abre en una pestaña nueva), checked 2026-11-01. ⟲
• Salesforce Help, How Einstein Search Works (se abre en una pestaña nueva), checked 2026-11-01: tokens, indexing time, the 120-day rule, ranking, languages. ⟲
• Salesforce Developers, SOQL and SOSL Limits for Search Queries (se abre en una pestaña nueva) (Limits Quick Reference) and Apex Developer Guide, Execution Governors and Limits (se abre en una pestaña nueva) and Set an Access Mode for Database Operations (se abre en una pestaña nueva), Winter ‘27, checked 2026-11-01. ⟲
• Salesforce Help, release notes, Database Operations Run in User Mode by Default, Not System Mode (se abre en una pestaña nueva), API version 67.0, checked 2026-11-01. ⟲
• Salesforce Architects, Well-Architected, Trust (se abre en una pestaña nueva), checked 2026-11-01: SOQL and SOSL injection. ⟲
• Salesforce Developers, Hosted MCP Servers, SObject All (se abre en una pestaña nueva), checked 2026-11-01: the find tool. ⟲
• Salesforce Help, How Search Crowding Affects Search Results (se abre en una pestaña nueva), checked 2026-11-01: the definition, the numbers and the suggestions. ⟲
• Salesforce Help, Search Manager: Manage Searchable Objects and Fields (se abre en una pestaña nueva), Manage the Search Index (se abre en una pestaña nueva), Explore the Search Index with Search Manager (se abre en una pestaña nueva), and Searchable Fields: Custom Object (se abre en una pestaña nueva), checked 2026-11-01. ⟲