Cómo encuentra Salesforce tus datos
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)
Módulo 2 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: Dentro del motor de Salesforce · Siguiente: Cuándo usa Salesforce un índice
La pregunta que responde este módulo: ¿qué es un índice y cuáles te da Salesforce?
En el módulo anterior abrimos el motor y encontramos un problema: tus registros viven en ranuras compartidas donde no encaja un índice normal de base de datos, así que Salesforce copia los valores indexados a tablas separadas hechas para encontrarlos. Ahora veamos por qué importa. Y para esto, me gustan las analogías.
Visita a una biblioteca
Sección titulada «Visita a una biblioteca »Piensa en una biblioteca. Una grande: un edificio lleno de salas, y las salas llenas de estanterías, pasillo tras pasillo. ¿Qué hay dentro? Libros. Muchos libros.
Entras buscando un libro. No sabes el título completo. Sabes que empieza por la palabra “Fontanería”. Los libros están en las estanterías en el orden propio de la biblioteca, no por orden de título. Entonces, ¿cómo lo encuentras?
Empiezas por el primer pasillo. Coges el primer libro, lees el título y lo devuelves. Siguiente libro. Siguiente libro. Para estar seguro de haber encontrado todos los libros cuyo título empieza por “Fontanería”, tienes que tocar todos los libros de la biblioteca.
¿Cómo llamamos a tener que tocar todos los registros para encontrar los que queremos? Un recorrido de la tabla (table scan). Un recorrido completo de la tabla. ¿Es rápido o lento?
Depende del número de libros. Con 10 libros, un recorrido de la tabla es rápido. Con 10.000, todavía bien. Según mi experiencia, es a partir del millón cuando empiezas a notarlo, y con 50 millones una consulta que recorre la tabla puede tardar varios segundos. No cambió nada de la pregunta. El bibliotecario no se volvió más lento. Cambió el número de libros. Por eso importa el volumen: cuantos más libros hay en la biblioteca, más tarda el recorrido de la tabla.
Imagen generada con IA.
La tecnología avanzada: los catálogos de fichas
Sección titulada «La tecnología avanzada: los catálogos de fichas »¿Y cómo resolvieron esto las bibliotecas? Hace mucho tiempo inventaron una tecnología muy avanzada. (Lo digo en broma.) Los catálogos de fichas. Grandes muebles de cajoncitos, llenos de fichas pequeñas. Cada ficha tiene un poco de información sobre un libro, el título por ejemplo, y la ubicación del libro en las estanterías.
Siempre hay alguien que dice: ¿por qué no ordenar los libros por título y ya está? De acuerdo. Ahora quiero todos los libros sobre reparaciones del hogar. No puedes ordenar los mismos libros por título y por tema. Pero con fichas sí puedes. Copia las fichas y archiva un juego por título, un segundo juego por tema, un tercero por autor. Los libros se quedan donde están.
Entonces, ¿qué representan las fichas? Un índice. Una pequeña copia de unos pocos datos de cada libro, ordenada por un campo, para que puedas ir directamente al cajón correcto en lugar de recorrer los pasillos. (Las bases de datos mantienen ese orden en estructuras ordenadas especiales. No necesitas los detalles.) Encuentras la ficha, lees la ubicación y luego vas a buscar el libro.
En esos cajones hay tres ideas, y son las tres que quiero que te lleves a Salesforce:
- Un índice es una copia. La ficha no es el libro; es una pequeña copia de unos pocos datos. Salesforce dice lo mismo de sus propios índices: la plataforma “crea una tabla de índice que contiene una copia de los datos” (Best Practices for Deployments with Large Data Volumes (se abre en una pestaña nueva), Winter ‘27).
- Puede haber más de un índice. Un juego de fichas por título, otro por tema, otro por autor. Cada uno responde rápido a una pregunta distinta. En Salesforce, cada campo indexado es su propia vía de entrada.
- La ficha te dice dónde está el libro. En Salesforce, la entrada del índice apunta al registro, y la plataforma va directamente a él. Los ingenieros de bases de datos de Salesforce describen exactamente eso: “La entrada del índice está formada por los campos clave del índice seguidos de los campos de clave primaria del registro correspondiente de la tabla base” (A Multi-tenant Relational OLTP Database at Salesforce (se abre en una pestaña nueva), CIDR 2026). Una copia de un campo, y luego la ubicación del libro.
Imagen generada con IA.
Encontrar un libro
Sección titulada «Encontrar un libro »Entonces, ¿qué pasa cuando usas el catálogo? Supongamos que buscas el libro titulado Fontanería básica. Hay tres pasos:
- Encuentra la ficha. Ve al cajón de fichas por título y saca la ficha de Fontanería básica.
- Lee la ubicación. La ficha te dice dónde está el libro: el pasillo, la estantería, el lugar en la estantería.
- Coge el libro. Ve directamente a ese lugar y sácalo de la estantería.
Has tocado una ficha y un libro, no todos los libros de la biblioteca. Eso es lo que un índice puede hacer por una consulta. Salesforce encuentra la entrada en el índice, lee a qué registro apunta y va directamente a ese registro. Usar el índice puede acelerar enormemente la recuperación, y cuanto más grande es la biblioteca, mayor es la diferencia. Fíjate en la palabra “puede”: si Salesforce usa de verdad el catálogo es una decisión a la que llegaremos en el próximo módulo.
Encuentra la ficha, lee la ubicación, coge el libro.
Cada copia hay que mantenerla al día
Sección titulada «Cada copia hay que mantenerla al día »Ahora sigue el catálogo de fichas un paso más. Llega un libro nuevo. El bibliotecario lo pone en la estantería, y ahí no termina el trabajo. Alguien tiene que escribir una ficha por título, una por tema y una por autor, y archivar cada una en el cajón correcto. ¿Cambia un libro? Busca todas las fichas que guardan lo que cambió y reescríbelas: dale al libro un título nuevo y un tema nuevo, y son dos fichas que sacar, reescribir y volver a archivar, además de cambiar el propio libro. Las actualizaciones tampoco son gratis. Cuantos más juegos de fichas mantiene la biblioteca, más trabajo supone cada libro nuevo.
Ese es el intercambio que quiero que tengas presente en todo este capítulo: rendimiento de lectura frente a rendimiento de escritura. Cada índice hace más rápido encontrar registros, porque es una copia pequeña y ordenada. Cada índice hace más lento guardar registros, porque cada inserción, y cada actualización de un campo indexado, tiene que actualizar también esa copia, y Salesforce lo hace en ese mismo momento, en la misma transacción: la plataforma mantiene su índice “copiando de forma síncrona los datos de los campos marcados para indexar” a una tabla de índice separada (Platform Multitenant Architecture (se abre en una pestaña nueva)). Diez índices en un objeto significan diez copias que revisar en cada guardado. Más índices, lecturas más rápidas, escrituras más lentas.
Y recuerda el tamaño de la biblioteca. Con unos cientos de libros, recorrer los pasillos es rápido y el catálogo de fichas es trabajo extra para poca ganancia. Con 10 millones de libros, el recorrido de la tabla es el problema y el índice es la respuesta. Las bibliotecas pequeñas pueden vivir con recorridos de la tabla; las grandes necesitan índices.
Así que no miro cada campo y digo “¿por qué no los indexamos todos?”. Supón que Steve Trucking indexara el número de entrega, el socio minorista, el destinatario, el estado, la fecha programada, el código postal, el camión, el equipo y la ruta. Cada uno podría ayudar a alguna búsqueda; cada uno es otro juego de fichas que mantener al día en cada guardado. La pregunta del arquitecto no es ¿se puede indexar este campo? Es ¿indexarlo sostiene una forma importante y repetible de encontrar registros con la fuerza suficiente para justificar el coste en cada escritura? Los índices no son magia. Son arquitectura.
Añadir un libro: una ficha en cada cajón.
Actualizar un libro: cada dato indexado que cambia es otra escritura. Lecturas más rápidas, escrituras más lentas.
A veces me dicen que los arquitectos no necesitan saber esto, porque Salesforce se encarga. Salesforce se encarga, sí. Aun así quiero que lo entiendas, porque entonces varios comportamientos cobran sentido. ¿Por qué un índice tiene un coste de escritura? Porque hay que actualizar otra copia en cada guardado. ¿Por qué importa la distribución de los valores? Un índice que apunta a casi toda la tabla no es un atajo. ¿Por qué podría Salesforce no usar un índice que existe? Porque a veces recorrer las estanterías es realmente más barato que usar el catálogo.
Dos maneras de preguntar
Sección titulada «Dos maneras de preguntar »Hay dos maneras de pedirle registros a Salesforce. SOQL, el Salesforce Object Query Language, empieza por la palabra SELECT: nombras el objeto, los campos y las condiciones, de forma muy parecida a SQL. SOSL, el Salesforce Object Search Language, empieza por FIND: buscas texto en muchos objetos a la vez. La mayoría escribimos SELECT casi siempre, pero SOSL está trabajando cada vez que alguien usa la búsqueda global. Y las dos preguntas van a dos motores distintos. SELECT va a la base de datos, a través de los índices que acabamos de ver. FIND va al motor de búsqueda de Salesforce: “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). Este capítulo trata sobre todo de SELECT; el módulo 5 trata de FIND.
Dos preguntas, dos lenguajes, dos motores.
Índices estándar
Sección titulada «Índices estándar »Volvamos a SELECT y al catálogo de fichas. La biblioteca tiene cajones. ¿Qué cajones mantiene ya Salesforce para ti? De serie, sin que nadie lo pida, la plataforma indexa una lista corta de campos en la mayoría de los objetos. En la propia lista de Salesforce: RecordTypeId, Division, CreatedDate, Systemmodstamp (LastModifiedDate), Name, Email (en contactos y prospectos), las relaciones de clave externa (búsquedas y principal-detalle) y “el ID de registro único de Salesforce, que es la clave primaria de cada objeto” (Indexes (se abre en una pestaña nueva), Winter ‘27). Esos son tus índices estándar. Filtra por uno de ellos y hay un cajón esperándote.
Esa lista dice “la mayoría de los objetos”, así que ¿cómo se ve en un objeto real? Salesforce no publica una tabla por objeto, así que hicimos la nuestra. Cada campo de Salesforce lleva un indicador, IsIndexed: “Si es true, el campo está indexado en la base de datos” (FieldDefinition (se abre en una pestaña nueva), Tooling API, Winter ‘27). Leímos ese indicador en una organización Developer Edition el 2026-10-21 (versión 68.0 de la API). Tu organización puede ser distinta, porque algunos campos indexados solo existen cuando se activa una función: RecordTypeId cuando el objeto tiene tipos de registro, Division cuando se habilitan las divisiones.
Índices estándar en objetos estándar (indexados de serie, antes de que nadie lo pida):
| Objeto | Indexados de serie |
|---|---|
| Account | Id, Name, OwnerId, ParentId, CreatedDate, SystemModstamp, OperatingHoursId |
| Contact | Id, Name, Email, AccountId, ReportsToId, OwnerId, IndividualId, CreatedDate, SystemModstamp |
| Lead | Id, Name, Company, Email, OwnerId, ConvertedAccountId, ConvertedContactId, ConvertedOpportunityId, IndividualId, CreatedDate, SystemModstamp |
| Opportunity | Id, Name, AccountId, ContactId, CloseDate, CampaignId, Pricebook2Id, ContractId, PrimaryPartnerAccountId, OwnerId, CreatedDate, SystemModstamp |
| Case | Id, CaseNumber, Status, IsClosed, ClosedDate, AccountId, ContactId, AssetId, ProductId, EntitlementId, ServiceContractId, ParentId, OwnerId, CreatedDate, SystemModstamp |
| Task | Id, WhoId, WhatId, AccountId, ActivityDate, Status, OwnerId, CreatedDate, CreatedById, SystemModstamp |
(También están indexadas algunas búsquedas más hacia funciones antiguas u opcionales: los ID de empresa de Data.com y D&B en Account, Contact y Lead, RuleFilterId en Case y RecurrenceActivityId en Task.)
Índices estándar en objetos personalizados. Cada objeto personalizado recibe los mismos campos estándar (Campos estándar de objeto personalizado (se abre en una pestaña nueva)), y estos están indexados desde el día en que lo creas:
| En cada objeto personalizado | ¿Indexado de serie? |
|---|---|
| Id (el ID de registro) | Sí |
| Name | Sí |
| OwnerId (objetos con propietario; en un objeto de detalle decide el principal) | Sí |
| CreatedDate | Sí |
| SystemModstamp | Sí |
| IsDeleted (en la Papelera de reciclaje o no) | Sí |
| RecordTypeId | Sí, cuando el objeto tiene tipos de registro |
| Cada campo de búsqueda y de principal-detalle que añades | Sí |
| CreatedById, LastModifiedById | No |
| LastModifiedDate | No: el indexado es SystemModstamp |
| Cualquier otro campo personalizado | No, hasta que lo pidas (siguiente sección) |
Mira esas tablas un minuto, porque dicen mucho. Name está, así que encontrar un registro por su nombre tiene un camino. Todas las búsquedas están, así que encontrar los registros hijos de un padre (las órdenes de trabajo de una cuenta, las partidas de una orden de trabajo) tiene un camino. CreatedDate y SystemModstamp están, así que “lo nuevo” y “lo que ha cambiado desde ayer” tienen un camino. Y mira Case: Status, IsClosed y ClosedDate están indexados. Quédate con eso; importa en el próximo módulo. Si una de tus formas importantes de encontrar registros ya está en estas tablas, empiezas con ventaja. Para ver tu propia organización, abre el objeto en el Gestor de objetos y mira Campos y relaciones, donde cada campo muestra si está indexado.
Conocimiento para el examen. Conoce los campos indexados estándar de Salesforce: RecordTypeId, Division, CreatedDate, Systemmodstamp (LastModifiedDate), Name, Email en contactos y prospectos, los campos de búsqueda y de principal-detalle, y el ID de registro.
Índices personalizados
Sección titulada «Índices personalizados »¿Y si el campo por el que buscas no está en la lista? ¿Alguien sabe cómo crear un índice personalizado en Salesforce? De dos maneras, en palabras de Salesforce: “Puedes crear índices personalizados contactando con el servicio de atención al cliente de Salesforce o implementando un archivo XML de índice personalizado mediante Metadata API” (misma fuente). Los que crea el soporte en producción “se copian a todos los sandboxes que crees a partir de ese entorno de producción”. Incluso el camino de Metadata API empieza con una conversación: el tipo CustomIndex dice que revises la orientación de Salesforce sobre los índices “y después te pongas en contacto con el servicio de atención al cliente de Salesforce” (CustomIndex (se abre en una pestaña nueva), Metadata API Developer Guide, Winter ‘27).
And there’s a quieter way, one I always ask about in class. Mark the field as an External ID. “External IDs cause an index to be created on that field. The query optimizer then considers those fields” (same source). Only some field types can be External IDs: Auto Number, Email, Number and Text. The same goes for marking a custom field Unique: Salesforce lists “Custom fields that are marked as External ID or Unique” among the fields indexed by default (Working with Very Large SOQL Queries (se abre en una pestaña nueva), Apex Developer Guide, Winter ‘27). Steve Trucking already did this without thinking about it. Each Retail Partner sends its own delivery reference, say DLV-8472914, and we made that field an External ID so integrations could match on it. That field got a drawer of its own. ⟲
Salesforce también hace ahora parte de esto por ti. La misma página dice: “Los campos que no están indexados por defecto se indexan automáticamente cuando el optimizador de Salesforce reconoce que un índice puede mejorar el rendimiento de las consultas que se ejecutan con frecuencia.” Así que una organización puede tener índices que nadie pidió. Pero no diseñes con la esperanza de que ocurra: Salesforce no dice qué consultas cumplen los requisitos ni cuándo, así que comprueba el campo en el Gestor de objetos en lugar de suponerlo.
Entonces, ¿lo indexamos todo? Recuerda que cada copia hay que mantenerla al día: cada cajón es otra ficha que escribir en cada guardado. En clase digo que cada solicitud de índice personalizado es una conversación, y que deberías llegar con un buen argumento: la consulta, el volumen, cómo se reparten los valores y por qué. No es que Salesforce ponga trabas. Tú tampoco quieres índices ilimitados. Podrías acelerar tus consultas y ralentizar cada inserción y cada actualización.
Conocimiento para el examen. Un índice personalizado se obtiene del servicio de atención al cliente de Salesforce o mediante Metadata API, y marcar un campo personalizado como External ID (Numeración automática, Correo electrónico, Número o Texto) o como Único lo indexa.
Qué campos se pueden indexar
Sección titulada «Qué campos se pueden indexar »Así que has encontrado el campo por el que filtra tu consulta importante, y no está en las tablas estándar. ¿Puede tener un cajón? Normalmente sí. Salesforce “admite índices personalizados en campos personalizados, excepto en áreas de texto (largas), áreas de texto (enriquecidas), campos de fórmula no deterministas y campos de texto cifrado” (Indexes (se abre en una pestaña nueva), Winter ‘27). La misma página enumera más campos que la plataforma no puede indexar: las listas de selección múltiple, los campos de divisa en una organización con más de una divisa, las áreas de texto largas y los campos binarios (un blob, un archivo o texto cifrado).
| Campo | ¿Se puede indexar? |
|---|---|
| Texto, Número, Correo electrónico, Numeración automática | Sí. Márcalo como External ID y obtienes el índice sin pedirlo |
| Fecha, Fecha/hora, Casilla de verificación, Lista de selección, Teléfono y la mayoría de los demás campos personalizados | Sí, como índice personalizado: pídelo al servicio de atención al cliente de Salesforce o impleméntalo con Metadata API |
| Búsqueda y principal-detalle | Ya indexados: son índices estándar |
| Campos estándar que no están en las tablas estándar | Pídelo al servicio de atención al cliente de Salesforce |
| Fórmula | Solo si es determinista (a continuación) |
| Área de texto (larga), Área de texto (enriquecida) | No |
| Lista de selección múltiple | No |
| Divisa, en una organización con más de una divisa | No |
| Texto cifrado (el campo de cifrado clásico, más antiguo) | No |
| A field encrypted with Shield Platform Encryption | Only with deterministic encryption, which “supports single-column indexes and single and double-column unique indexes” (Filter Encrypted Data with Deterministic Encryption (se abre en una pestaña nueva)) |
¿Por qué un área de texto larga no puede tener una ficha? Piensa en el catálogo de fichas. Una ficha guarda una pequeña copia de un dato. Un área de texto larga puede guardar una carta entera. Una lista de selección múltiple guarda varios valores en un campo. Ninguna de las dos es un valor único y corto que puedas ordenar en un cajón.
¿Se puede indexar un campo de fórmula?
Sección titulada «¿Se puede indexar un campo de fórmula? »Sí, con ciertas condiciones. “Se pueden crear índices personalizados en campos de fórmula deterministas” (misma fuente). Determinista significa que la fórmula siempre da la misma respuesta para el mismo registro hasta que alguien guarda ese registro. Entonces la plataforma puede hacer lo que hace con cada índice: escribir la ficha cuando se guarda el registro.
Una fórmula no determinista puede cambiar su respuesta sin que se guarde el registro, así que nadie actualizaría nunca su ficha. La razón de Salesforce: “Como algunos valores varían con el tiempo o cambian cuando una transacción actualiza una entidad relacionada, la plataforma no puede indexar fórmulas no deterministas” (misma fuente). Hay dos tipos de razones que conviene recordar:
- El valor cambia con el tiempo. La fórmula usa TODAY() o NOW(). “Días desde que se programó esta entrega” es un número distinto mañana, y no cambió nada del registro.
- El valor vive en otro objeto. La fórmula atraviesa una búsqueda o un principal-detalle, como
Account.Region__cen una orden de trabajo, o usa otra fórmula que lo hace. Cuando alguien edita la cuenta, cambia la respuesta de todas las órdenes de trabajo, y ninguna de esas órdenes de trabajo se guardó.
La misma página nombra unas cuantas más: fórmulas que usan el propietario, la numeración automática, la división o los campos de auditoría (CreatedDate y CreatedById son las excepciones), fórmulas que hacen referencia a un campo que a su vez no se puede indexar, y fórmulas que usan ciertos campos estándar con un comportamiento especial, como Amount e IsClosed de Opportunity, o IsClosed y ClosedDate de Case. Y si cambias una fórmula después de indexarla, el índice se reconstruye.
Entonces, ¿qué haces cuando la fórmula que querías llega a otro objeto? Salesforce apunta a una manera de sortearlo: filtrar a través de la relación en la propia consulta. “Siempre que el campo referenciado esté indexado, la notación entre objetos puede tener varios niveles” (misma fuente). En lugar de WHERE Account_Region__c = 'West' sobre una fórmula, escribe WHERE Account.Region__c = 'West' e indexa Region__c en la cuenta.
Conocimiento para el examen. Conoce qué campos no pueden tener un índice personalizado: las áreas de texto largas y enriquecidas, las listas de selección múltiple, el texto cifrado, la divisa en una organización multidivisa y las fórmulas no deterministas. Una fórmula solo se puede indexar si es determinista: sin TODAY() ni NOW(), y sin valores de otro objeto a través de una búsqueda.
Tablas de índices
Sección titulada «Tablas de índices »Una pieza más, y conecta con el motor. En el módulo 1 vimos que los valores de tus campos personalizados viven en columnas flexibles compartidas, donde una columna puede guardar un número de camión para una empresa y un sabor de helado para otra. Sobre eso no se puede construir un índice normal de base de datos. Entonces, ¿qué hace Salesforce? Hace una copia. “La arquitectura multiinquilino de Salesforce hace que la tabla de datos subyacente de los campos personalizados no sea adecuada para indexar. Para superar esta limitación, la plataforma crea una tabla de índice que contiene una copia de los datos, junto con información sobre los tipos de datos. La plataforma construye un índice estándar de base de datos sobre esta tabla de índice” (misma fuente). El catálogo de fichas es algo real, guardado en su propia tabla, y cada guardado lo mantiene sincronizado.
Del módulo 1: los valores indexados se copian a una tabla aparte, con tipo, hecha para encontrar.
Un detalle de esa misma página importa más adelante: “Por defecto, las tablas de índices no incluyen los registros nulos (registros con valores vacíos).” Un registro con un campo vacío no tiene ficha en ese cajón. Puedes pedir al servicio de atención al cliente de Salesforce índices personalizados que incluyan las filas nulas, y entonces los existentes hay que habilitarlos y reconstruirlos (misma fuente). Así que si “encontrar los registros en los que este campo está vacío” es una pregunta importante, planifícalo. El módulo 3 vuelve sobre ello.
Lo que decide aquí un arquitecto
Sección titulada «Lo que decide aquí un arquitecto »- Qué formas importantes de encontrar registros cubren ya los índices estándar.
- Qué campos justifican un índice personalizado (o un External ID), teniendo en cuenta la escritura extra en cada guardado.
- Si el tipo de un campo permite siquiera un índice, decidido cuando se diseña el campo, no cuando la consulta va lenta.
- Si importa encontrar valores vacíos, ya que las tablas de índices dejan fuera las filas nulas por defecto.
- Qué preguntas son preguntas SELECT para la base de datos y cuáles son preguntas FIND para la búsqueda.
Un recorrido de la tabla toca todos los libros. Un índice es el catálogo de fichas: una pequeña copia, un juego por índice, cada ficha apuntando al libro, y cada una actualizada en cada guardado. Salesforce mantiene algunos cajones por ti (índices estándar), construye otros cuando los pides (índices personalizados) y los guarda todos en tablas de índices, copias hechas para encontrar. Así que ya tenemos cajones. ¿Significa eso que todas las preguntas son rápidas? No. En el próximo módulo veremos las tres cosas que tienen que cumplirse para que Salesforce use uno.
Explora
Sección titulada «Explora »- 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 standard indexed fields, custom indexes and External IDs, which fields can’t be indexed, index tables as a copy of the data, and null rows. ⟲
- Salesforce Architects, Platform Multitenant Architecture (se abre en una pestaña nueva), checked 2026-11-01: indexed values copied synchronously into MT_Indexes. ⟲
- Salesforce Developers, Tooling API (Winter ‘27), FieldDefinition (se abre en una pestaña nueva), checked 2026-11-01: the IsIndexed flag on every field. ⟲
- Salesforce Developers, Apex Developer Guide (Winter ‘27), Working with Very Large SOQL Queries (se abre en una pestaña nueva), checked 2026-11-01: External ID and Unique fields are indexed by default; the optimizer can index other fields automatically. ⟲
- Salesforce Developers, Metadata API Developer Guide (Winter ‘27), CustomIndex (se abre en una pestaña nueva), checked 2026-11-01: deploying a custom index still starts with Salesforce Customer Support. ⟲
- Salesforce Help, Filter Encrypted Data with Deterministic Encryption (se abre en una pestaña nueva), checked 2026-11-01: deterministic encryption supports single-column indexes. ⟲
- Salesforce Help, Campos estándar de objeto personalizado (se abre en una pestaña nueva), checked 2026-11-01: the standard fields every custom object has. ⟲
- Salesforce Developers, Best Practices for Deployments with Large Data Volumes (Winter ‘27), Search Architecture (se abre en una pestaña nueva), checked 2026-11-01: search has its own data store. ⟲
- Arora and others (Salesforce), A Multi-tenant Relational OLTP Database at Salesforce (se abre en una pestaña nueva), CIDR 2026, checked 2026-11-01: an index entry is the index key followed by the record’s primary key. ⟲
- En este curso: Dentro del motor de Salesforce, el módulo anterior a este.