Reportes, dashboards y formulas en Salesforce

El modelo mental: pregunta, datos y nivel de calculo

Una pregunta de reportes rara vez se trata solo de "hacer un reporte". Normalmente esta probando si puedes traducir una pregunta de negocio a una estructura de datos. Primero identifica que quiere saber la persona: una lista de registros, un subtotal por grupo, una comparacion entre dos dimensiones, la existencia de registros relacionados o una visualizacion ejecutiva. Despues decide que datos necesita el reporte y en que nivel debe ocurrir el calculo.

El error comun es brincar directo a dashboards o formulas. Un dashboard no arregla un reporte mal construido. Una formula de objeto no siempre es necesaria si el calculo vive solo dentro de un reporte. Un bucket field puede agrupar valores para analisis sin crear campos nuevos. Y un cross filter puede responder preguntas de "con" o "sin" registros relacionados sin inventar una formula complicada.

Regla practica: report type decide que datos puedes usar; formato decide como se organizan; filtros deciden que entra; formulas y buckets deciden como se calcula o agrupa.

Report types y relaciones

El report type es la puerta de entrada. Define el objeto principal, los objetos relacionados disponibles y si el reporte muestra registros con o sin relaciones. Si eliges mal el report type, puedes pasar mucho tiempo buscando campos que nunca apareceran. Por eso una pregunta que menciona Accounts with Opportunities, Cases with Activities o Contacts without Campaign History no solo habla de filtros; tambien puede estar probando la relacion de datos del report type.

Los report types estandar cubren muchos escenarios comunes, pero custom report types ayudan cuando necesitas una combinacion especifica de objetos o campos. En el examen, custom report type suele ser candidato cuando los usuarios no pueden crear un reporte con la relacion o los campos que necesitan usando tipos estandar. No lo elijas por costumbre: primero confirma si la necesidad realmente no cabe en un report type existente.

Tambien recuerda la seguridad. Tener acceso a una carpeta de reportes no significa ver todos los datos del reporte. Los resultados respetan permisos, field-level security y sharing del usuario, salvo el comportamiento especifico de dashboards con running user. Esta distincion aparece en preguntas donde alguien puede abrir el reporte pero no ve ciertos registros o campos.

Formatos de reporte

Tabular es el formato mas simple: una lista de filas y columnas. Es bueno para exportaciones, listas operativas y detalles sin agrupacion. Si una pregunta pide "lista de todos los contactos con email faltante", tabular puede ser suficiente. Pero si necesita graficas, subtotales o comparaciones, probablemente necesitas otro formato.

Summary agrupa filas por una dimension y permite subtotales. Es util para preguntas como oportunidades por etapa, casos por prioridad o ingresos por propietario. Matrix agrupa por filas y columnas, ideal para comparar dos dimensiones a la vez, como region por trimestre o producto por etapa. Joined combina bloques de reportes para ver datos relacionados en secciones separadas, aunque no siempre es la primera respuesta para Administrator si summary o matrix resuelve el caso.

En preguntas de examen, mira palabras como group by, summarize, compare across rows and columns o multiple blocks. Una dimension de agrupacion suele apuntar a summary. Dos dimensiones, una en filas y otra en columnas, apuntan a matrix. Una lista plana apunta a tabular. Varias vistas en bloques apuntan a joined.

Filtros, filter logic y cross filters

Los filtros reducen el conjunto de registros. Pueden ser filtros estandar, filtros por campo, filtros relativos de fecha o filter logic cuando necesitas combinar condiciones con AND y OR. Si el usuario dice "oportunidades abiertas de este trimestre para cuentas enterprise o strategic", la parte importante puede ser construir la logica correcta, no cambiar el formato.

Cross filters responden preguntas sobre existencia de registros relacionados: Accounts with Opportunities, Accounts without Opportunities, Cases with Activities o Contacts without Campaigns. Son muy importantes para el examen porque evitan soluciones falsas como formulas para contar hijos o filtros imposibles sobre campos que no existen en el objeto principal.

Si la pregunta dice "con al menos un registro relacionado" o "sin registros relacionados", piensa en cross filter. Si dice "filtrar por valores de campos", piensa en filtros normales. Si dice "varias condiciones combinadas", piensa en filter logic. Una buena respuesta mantiene el criterio dentro del reporte cuando no hace falta cambiar el modelo de datos.

Row-level formulas, summary formulas y bucket fields

Row-level formulas calculan un valor por cada fila del reporte. Sirven para preguntas como "cuantos dias estuvo abierto cada caso" o "marcar cada oportunidad segun margen". El resultado vive en el reporte y se evalua por registro mostrado. No es lo mismo que una formula field del objeto, que se guarda como configuracion reutilizable para muchos lugares de Salesforce.

Summary formulas calculan sobre grupos, subtotales o el total del reporte. Sirven para porcentajes, comparaciones entre agregados y metricas como win rate por region. Si la pregunta habla de calculo por grupo, subtotal, porcentaje del total o comparacion entre periodos, una summary formula es mejor candidata que una row-level formula.

Bucket fields agrupan valores dentro de un reporte sin crear un campo nuevo en el objeto. Por ejemplo, agrupar Amount en Small, Medium y Large, o agrupar industrias en segmentos. Si la agrupacion solo se necesita para un reporte, bucket field puede ser mas limpio que crear un campo custom. Si se necesita en muchas automatizaciones, layouts o integraciones, un campo real podria tener mas sentido.

Dashboards, running user y subscriptions

Un dashboard muestra componentes visuales basados en reportes fuente. No reemplaza al reporte; depende de el. Si un componente muestra datos incorrectos, revisa primero el source report, filtros, agrupaciones y seguridad. Dashboard filters permiten que el viewer cambie una dimension comun, como region, equipo o periodo, sin mantener muchas versiones del mismo dashboard.

El running user define que acceso a datos usa un dashboard estatico. Esto puede hacer que viewers vean datos segun el acceso del running user, no necesariamente segun su propio acceso. Dynamic dashboards, cuando estan disponibles, ejecutan el dashboard como el usuario que lo esta viendo. En preguntas de seguridad, esta diferencia importa mucho: ejecutivos que necesitan ver su propio territorio pueden apuntar a dynamic dashboard; una vista ejecutiva central puede apuntar a running user especifico.

Subscriptions sirven para recibir reportes o dashboards por correo en un horario. Report subscriptions pueden incluir condiciones, por ejemplo enviar solo si los casos abiertos superan cierto numero. Si la pregunta dice notificar cuando una metrica cruza un umbral, subscribe to the report with conditions suele ser candidato. Si solo pide una vista interactiva, no confundas subscription con dashboard filter.

Errores comunes al estudiar analytics

El primer error es confundir el nivel de calculo. Si el resultado debe aparecer en cada fila, piensa row-level. Si el resultado se calcula por grupo o total, piensa summary formula. Si la necesidad es agrupar valores para leerlos mejor, piensa bucket. Si la formula se necesita fuera del reporte, evalua formula field en el objeto.

El segundo error es usar dashboards para resolver preguntas de datos. Un dashboard visualiza; no crea relaciones que no existen ni corrige filtros mal hechos. El tercer error es olvidar seguridad: folder sharing da acceso al artefacto, pero los datos visibles dependen de permisos, sharing y running user. El cuarto error es usar reportes cuando la pregunta realmente habla de automatizacion, validacion o almacenamiento permanente.

Lee con cuidado palabras como row, group, total, dashboard viewer, running user, without related records, conditional email, filter by region y compare quarter by product. Esas palabras casi siempre revelan la herramienta correcta.

Checklist de decision rapida:

La pregunta pide lista, agrupacion, matriz, bloques o visualizacion?
El report type contiene los objetos y relaciones necesarias?
La condicion es filtro normal, filter logic o cross filter?
El calculo es por fila, por grupo o solo una agrupacion visual?
El dashboard debe respetar al viewer o a un running user definido?

Recursos oficiales y practica

Para estudiar este tema, crea un mismo escenario en varias formas. Haz una lista tabular, luego una agrupacion summary, despues una matriz por dos dimensiones y finalmente un dashboard con un filtro. Practica tambien una row-level formula, una summary formula y un bucket field. La meta es reconocer el nivel correcto antes de mirar opciones.

BlueForce no esta afiliado a Salesforce. Esta guia es contenido editorial original basado en experiencia de estudio, objetivos publicos y recursos oficiales.