Cómo filtrar con CAML en SharePoint paso a paso

Cuando empiezas a trabajar en serio con listas y bibliotecas de SharePoint, tarde o temprano aparece el mismo problema: los filtros de la interfaz se quedan cortos. Filtrar por varias columnas, mezclar condiciones AND y OR, trabajar con fechas relativas o con usuarios… todo eso es posible, pero la interfaz gráfica no siempre da para tanto. Ahí es donde entra en juego CAML.

CAML (Collaborative Application Markup Language) es un lenguaje basado en XML que utiliza SharePoint para definir consultas, vistas, ordenaciones y muchas otras operaciones internas. Si entiendes cómo construir y filtrar con CAML en SharePoint, puedes exprimir al máximo las listas, ya sea desde PowerShell, C#, JavaScript, CSOM, REST o incluso al diseñar vistas avanzadas.

Qué es CAML y por qué es clave para filtrar en SharePoint

CAML es un lenguaje de marcado específico de SharePoint que se usa para describir qué datos quieres obtener y cómo quieres que se devuelvan. No es un lenguaje de programación, sino una forma estructurada de indicar a SharePoint: “dame estos elementos, con estas condiciones y en este orden”.

La parte más utilizada a diario por desarrolladores y administradores es el bloque <Where> de una consulta CAML, donde se definen los filtros. Además, se pueden combinar con nodos como <OrderBy>, <GroupBy> o <RowLimit> para afinar todavía más qué registros devuelve una lista.

En esencia, una consulta CAML típica que filtra datos en una lista de SharePoint tiene esta estructura general (simplificada): <Query> <Where>…filtros…</Where> <OrderBy>…</OrderBy> </Query>. Dentro del <Where> se encadenan las distintas condiciones sobre columnas.

SharePoint utiliza CAML por debajo en muchas características de la plataforma: vistas de listas, búsquedas internas, Web Parts de contenido, formularios personalizados y código servidor/cliente. Es decir, aunque no lo veas, CAML está trabajando siempre en segundo plano.

Cuando necesitas ir más allá de los filtros básicos de la interfaz o cuando trabajas con código, conocer CAML marca la diferencia, porque permite construir consultas complejas y muy precisas que serían imposibles de definir solo clicando en la UI.

Estructura básica de una consulta CAML para filtrar en SharePoint

Para poder filtrar con CAML de forma eficaz hay que entender bien su estructura mínima. Una consulta centrada en filtros suele girar alrededor de tres secciones principales: <Query>, <Where> y <OrderBy>. En ocasiones también se combina con <ViewFields> o <RowLimit>, pero lo esencial para filtrar está en <Where>.

La forma más habitual de usar CAML en código es a través de métodos como SPList.GetItems(SPQuery) en el modelo de servidor, o mediante consultas en CSOM/JSOM, donde asignas una cadena XML a la propiedad Query de un objeto de consulta. Esa cadena contiene los nodos XML que indican cómo filtrar la lista.

Un ejemplo muy simple de consulta CAML que filtra una lista por el valor exacto de una columna de texto podría tener esta forma: <Query><Where><Eq><FieldRef Name=’Title’ /><Value Type=’Text’>Tarea 1</Value></Eq></Where></Query>. Aunque la sintaxis pueda parecer rígida al principio, en cuanto entiendes el patrón, escalar a condiciones más complejas resulta bastante directo.

Lo importante es asimilar que cada condición se expresa usando operadores XML (Eq, Neq, Lt, Gt, Contains, etc.), siempre entre <FieldRef> (la columna) y <Value> (el valor que buscamos). A partir de ahí se pueden anidar y combinar esas condiciones tanto como necesitemos.

En muchas guías de CAML verás también la sección <View>, dentro de la cual se incluyen <Query>, <ViewFields> y <RowLimit>. Para filtrar, lo crítico es qué pones dentro de <Where>, aunque conviene no perder de vista que <OrderBy> y <GroupBy> influyen en el resultado que ves o que recibes en código.

Operadores de filtrado más usados en CAML

Cuando hablamos de filtrar con CAML en SharePoint, al final todo se reduce a escoger el operador adecuado para la condición que quieres aplicar. CAML ofrece un conjunto bastante amplio de operadores, aunque en la práctica hay un grupo reducido que se utiliza constantemente en proyectos reales.

Los operadores de comparación básicos son probablemente los más frecuentes: <Eq> (igual), <Neq> (distinto), <Lt> (menor que), <Gt> (mayor que), <Leq> (menor o igual) y <Geq> (mayor o igual). Estos se usan sobre todo con números, fechas y algunos campos de texto.

Cuando necesitas buscar cadenas o patrones dentro de un texto, entran en juego operadores como <Contains> y <BeginsWith>. El primero comprueba si el texto de la columna contiene el fragmento indicado, y el segundo valida si el valor de la columna empieza por una determinada cadena. Son muy útiles para filtros “tipo búsqueda” sobre columnas de texto.

También existen operadores más avanzados: <IsNull> y <IsNotNull> para saber si una columna está vacía o tiene algún valor; <In> para comprobar si el valor de un campo se encuentra dentro de una lista concreta de valores; y operadores específicos de usuarios y permisos, como <Membership>, cuando necesitas filtrar por pertenencia a grupos.

En campos booleanos, lo habitual es usar <Eq> con valores true/false (o su equivalente numérico 1/0, según el tipo), mientras que para campos de búsqueda, usuario o búsqueda administrada hay que combinar operadores con tipos de valor específicos (Lookup, User, etc.). Al final, buena parte de la potencia de CAML está en elegir con precisión el operador más adaptado a cada tipo de columna.

Combinar condiciones: AND, OR y anidación de filtros

En casi cualquier escenario real, filtrar una lista implica usar más de una condición a la vez. Por ejemplo, seleccionar tareas asignadas a un usuario concreto que además estén activas y con fecha de vencimiento futura. CAML permite combinar condiciones mediante dos operadores lógicos: <And> y <Or>.

La clave está en que <And> y <Or> se utilizan como nodos que engloban dos condiciones internas. Es decir, cada <And> o <Or> solo puede tener dos hijos, que pueden ser condiciones simples (Eq, Lt, etc.) o a su vez otros <And> y <Or> anidados. De esta manera se generan árboles de condiciones tan complejos como se necesite.

Por ejemplo, para filtrar elementos cuyo estado sea “Activa” y además el campo Prioridad sea “Alta”, se construye algo como: <Where><And>…condición estado… …condición prioridad…</And></Where>. Y si hay que mezclar AND y OR, se anidan varias capas de estos operadores lógicos.

Una cuestión importante cuando se combinan muchas condiciones es el orden de evaluación. El orden lo marca la estructura del XML, no la prioridad típica de AND/OR que conocemos de otros lenguajes. Por ello, conviene dibujar mentalmente (o en papel) cómo quieres que se agrupe cada conjunto de filtros antes de traducirlo a CAML.

En escenarios más avanzados, por ejemplo al filtrar por varias categorías o por rangos de fechas combinados, es habitual acabar con estructuras de <And> y <Or> de tres o cuatro niveles de anidación. En esos casos, mantener el XML bien formateado y documentado es fundamental para no volverse loco al mantener la consulta con el tiempo.

Tipos de columnas y tratamiento específico en CAML

Uno de los errores más habituales al construir filtros CAML es no respetar el tipo real de la columna. Aunque a nivel visual muchas columnas parezcan “texto”, internamente SharePoint las trata de manera diferente, y CAML requiere especificar el tipo correcto en el nodo <Value>.

En columnas de texto simple o varias líneas, lo normal es usar Type=’Text’ o Type=’Note’, combinados con operadores como Eq, Neq, Contains o BeginsWith. En cambio, una columna de número exige Type=’Number’, y una de moneda suele ir como Type=’Currency’. Si te equivocas de tipo, el filtro no devolverá nada o, peor aún, devolverá resultados inexactos.

Las columnas de fecha y hora son especialmente delicadas. En CAML se tratan como Type=’DateTime’ y requieren pasar el valor en formato ISO (por ejemplo, 2026-03-29T00:00:00Z). Además, es posible usar el atributo IncludeTimeValue para indicar si se debe tener en cuenta la hora o solo la fecha.

En campos de búsqueda (Lookup), usuario (User), elección múltiple (MultiChoice) o búsqueda administrada, el tratamiento es diferente. Para un campo de usuario suele usarse Type=’User’ o ‘Integer’ con el ID interno del usuario, mientras que los campos de búsqueda trabajan con Type=’Lookup’ y, a menudo, con el ID del elemento de la lista de origen.

Otro grupo particular son las columnas booleanas, que normalmente se manejan con Type=’Integer’ (0 o 1) o Type=’Boolean’ (TRUE/FALSE), según cómo esté definida internamente la columna. A la hora de filtrar es muy importante revisar en la documentación de Microsoft o en herramientas de ejemplo qué combinación de tipo y valor espera CAML para cada caso concreto.

Filtrar por fechas en CAML: rangos, hoy y fechas relativas

Muchas consultas complejas de listas de SharePoint giran en torno al tiempo: elementos creados recientemente, vencimientos próximos, tareas atrasadas, etc.. CAML ofrece diversas opciones para filtrar por fechas, pero hay que manejar bien la sintaxis y el formato.

Para una fecha exacta, se utiliza un valor DateTime concreto en el nodo <Value>. Sin embargo, lo más habitual es filtrar por rangos, combinando operadores como <Geq> y <Leq> sobre la misma columna. Así se pueden obtener, por ejemplo, todos los elementos entre dos fechas determinadas.

SharePoint también permite usar tokens especiales como y dentro de algunas expresiones de vistas y dentro de determinadas consultas, sobre todo al trabajar con la interfaz avanzada de filtros o con CAML generado automáticamente. Estos tokens representan la fecha actual (con o sin hora) en el momento de ejecutar la consulta.

Además de , existen formas de usar fechas relativas mediante desplazamientos (offsets), por ejemplo para obtener elementos de los últimos 7 días o de los próximos 30. Internamente, estas expresiones se traducen a comparaciones con la fecha actual modificada, pero el detalle exacto de la sintaxis puede variar según se use en vistas, en código del lado servidor o en REST.

Conviene también tener en cuenta la zona horaria y el almacenamiento interno de las fechas. SharePoint guarda internamente los DateTime en UTC, y luego aplica ajustes de zona horaria en la presentación. Si se construyen fechas manualmente para CAML desde código, es recomendable ser coherente y trabajar siempre con UTC para evitar resultados desfasados.

Filtrar por usuario y permisos en CAML

Otra necesidad muy frecuente es limitar los resultados de una lista a elementos relacionados con el usuario actual o con miembros de un determinado grupo. CAML incorpora operadores específicos para manejar campos de usuario y criterios basados en membresía.

Para filtrar por un usuario concreto en una columna de tipo Person or Group, lo habitual es usar <Eq> con Type=’Integer’ o Type=’User’ y pasar el ID interno del usuario de SharePoint en el nodo <Value>. Este ID suele obtenerse desde el contexto de usuario o mediante una consulta previa en código.

Además, existe el operador <Membership> que permite crear filtros basados en la pertenencia del usuario actual a grupos, sitios o audiencias. Por ejemplo, se puede construir una condición que seleccione elementos en los que una columna de usuario contenga miembros del mismo grupo de SharePoint que el usuario que ejecuta la consulta.

Combinando <Membership> con operadores como <And> y <Or> se logran escenarios del tipo “elementos asignados a mí o a mi equipo”, “elementos de mi departamento”, etc., sin necesidad de hardcodear usuarios concretos en el XML de la consulta.

Todo esto convierte a CAML en una herramienta muy potente para implementar seguridad a nivel de datos, ya sea filtrando en vistas, en Web Parts o en código. Aunque la seguridad real se basa en permisos, filtrar por usuario ayuda a mostrar solo lo relevante y a mejorar la experiencia del usuario final.

Uso de CAML en código: servidor, cliente y REST

Filtrar con CAML en SharePoint no se limita a vistas configuradas desde la interfaz. De hecho, el uso más avanzado aparece cuando se integra CAML en código, ya sea desde el modelo de objetos del servidor, desde CSOM/JSOM o incluso en llamadas REST.

En el modelo de servidor clásico (SharePoint on-premises), se construye un objeto SPQuery y se asigna la cadena CAML a su propiedad Query. Luego se llama a métodos como SPList.GetItems(SPQuery) para obtener solo los elementos que cumplan los filtros. Aquí, además de la sección <Where>, se puede configurar <RowLimit> y opciones de paginación.

Con CSOM (Client-Side Object Model) y JSOM (JavaScript Object Model), el enfoque es similar, pero ejecutado desde aplicaciones cliente o scripts. Se define un objeto de consulta, se asigna el fragmento CAML y se ejecuta la carga de elementos contra el servidor de SharePoint, que procesa la consulta en segundo plano.

Cuando se trabaja con la API REST de SharePoint, el filtrado suele hacerse con parámetros OData como $filter, pero en múltiples escenarios internos SharePoint traduce esos filtros a CAML para ejecutar la consulta real. Además, hay endpoints y características donde se permite incluir directamente bloques CAML en el cuerpo de la petición.

En cualquier caso, sea cual sea el modelo utilizado, el principio es el mismo: construir bien la consulta CAML y asegurar que el XML es válido. Muchos errores típicos (paréntesis mal cerrados, etiquetas desordenadas, tipos de datos incorrectos) se traducen en resultados vacíos o en excepciones en tiempo de ejecución.

Herramientas y buenas prácticas para escribir consultas CAML

La sintaxis de CAML es muy estricta y, si la escribes a mano en bruto, es fácil que se cuele algún fallo. Por eso es recomendable apoyarse en herramientas y seguir ciertas buenas prácticas a la hora de construir y mantener consultas complejas.

Una recomendación clásica es usar generadores de CAML o “builders”, que permiten construir consultas con una interfaz más amigable y luego obtener el XML. Muchos administradores y desarrolladores también recurren a ejemplos documentados por Microsoft y a fragmentos de código probados en proyectos anteriores.

Validar siempre el XML antes de usarlo en producción es otra costumbre sana. No solo se trata de que sea XML bien formado, sino de asegurar que los nombres de las columnas (FieldRef Name) son correctos, que los tipos de dato coinciden con los de la lista y que los operadores utilizados son compatibles con ese tipo de campo.

En consultas extensas con muchos <And> y <Or>, ayuda mucho formatear el XML con sangrías claras y, si es posible, dejar comentarios en el propio código que expliquen qué hace cada bloque. Eso evita que, unos meses después, sea imposible entender por qué se construyó una estructura de filtros concreta.

Por último, es recomendable probar las consultas con pocos elementos antes de aplicarlas sobre listas grandes. Esto permite ajustar la lógica de filtrado sin penalizar el rendimiento ni saturar el servidor con consultas mal planteadas.

Dominar CAML para filtrar en SharePoint lleva un tiempo, pero el esfuerzo compensa: al final se consigue un control muy fino sobre qué datos se recuperan, cómo se combinan los criterios y de qué forma se presentan, algo prácticamente imprescindible en entornos corporativos con grandes volúmenes de información.