Serie 02 · Pensar antes de automatizar · Investigación 01/08 · Stephanie Herrera Bautista
Más allá de la pantalla
¿Qué cambia en el análisis de negocio cuando las capacidades dejan de depender de una interfaz? Una investigación sobre capacidades, experiencias y consumidores en Salesforce.
Una pantalla puede mostrar que una regla funciona
Eso no garantiza que la misma regla se cumpla cuando la operación se ejecuta desde otro canal.
Las arquitecturas Headless, las integraciones y los agentes amplían las formas de utilizar las capacidades de una organización. Para Business Analysis, la pregunta no es solo cómo llegar a ellas, sino qué condiciones deben seguir siendo válidas cuando cambia la forma de utilizarlas.
Esta entrega parte de un comportamiento documentado de Salesforce y lo lleva a una cuestión más amplia: ¿qué pertenece realmente al negocio y qué depende de la experiencia desde la que se interactúa con él?
Distinguir qué condiciones de negocio deben mantenerse cuando una capacidad se utiliza desde diferentes canales, qué aspectos pueden adaptarse y qué preguntas necesitas resolver antes de decidir cómo implementarla.
De dónde viene esta serie
La primera serie de Entre Líneas recorrió el camino desde comprender una necesidad hasta convertirla en trabajo verificable. Esta segunda serie explora qué sucede cuando las capacidades empresariales pueden utilizarse desde diferentes experiencias, integraciones y agentes. Los fundamentos del análisis de negocio permanecen; las preguntas que debes hacer adquieren nuevos matices.
El caso de esta entrega
Un caso hipotético de autorización de descuentos comerciales en Salesforce recorre los seis movimientos. No describe ninguna implantación real.
Aquí se analiza qué cambia en una capacidad cuando tiene varios consumidores. La autonomía de los agentes, la identidad, la evaluación y la gestión de datos aparecen solo cuando hacen falta para entender ese cambio. Cada una tendrá su propia investigación en la serie.
Lo que vas a recorrer
La regla que creíamos garantizada
Una organización registra en Salesforce las solicitudes de descuento comercial. Durante un workshop, Ventas y Finanzas acuerdan que ninguna solicitud debe guardarse sin una justificación comercial.
La configuración se resuelve en el Page Layout: el campo «Justificación» se marca como obligatorio.
Se prueba la pantalla. El usuario intenta guardar sin completar el campo y Salesforce se lo impide. La validación funciona.
¿Puede concluirse que la condición de negocio está garantizada? No necesariamente.
La documentación de Salesforce distingue entre las restricciones configuradas en el layout y las que se aplican a las operaciones realizadas mediante API. Un campo obligatorio en el Page Layout impide guardar desde esa interfaz. Esa configuración no se impone cuando otro consumidor crea o actualiza el registro mediante API.
Otras restricciones tienen un alcance distinto. Un campo obligatorio en su propia definición y las reglas de validación también se evalúan en las operaciones por API, aunque sus condiciones y excepciones deben comprobarse caso a caso.
Los permisos de acceso son otra cuestión. Que un campo no aparezca en un layout no significa que esté protegido frente a otros consumidores. El acceso depende de los permisos de objeto y de la seguridad a nivel de campo.
El problema no es que Salesforce haya dejado de aplicar una regla universal. Es que quizá nunca se estableció una regla universal.
La pantalla protegía una interacción concreta. El equipo podía estar interpretando ese comportamiento como una garantía para cualquier forma de ejecutar la operación.
Meses después, el equipo comercial pide aprobar descuentos desde una aplicación móvil y desde una herramienta de colaboración. En ese momento, la diferencia entre lo que protegía la pantalla y lo que exigía el negocio deja de ser teórica.
- ¿La justificación obligatoria responde a una condición del negocio o solo a una necesidad de esa experiencia?
- Si es una condición del negocio, ¿en qué rutas de ejecución debe cumplirse?
- ¿Qué mecanismo la garantiza hoy y cómo se ha comprobado?
Responderlas no implica trasladar todas las validaciones a la plataforma. Algunas restricciones son legítimamente propias de una experiencia. Lo importante es que esa diferencia sea una decisión consciente, no una consecuencia accidental del lugar donde se configuró la solución.
El comportamiento descrito procede de la documentación oficial de Salesforce sobre las operaciones de creación y actualización de la API y sobre seguridad a nivel de campo. Se refiere a Salesforce y no debe generalizarse a otras plataformas sin revisar su documentación. Tampoco cubre todos los mecanismos posibles: cada organización debe verificar cómo se comportan sus propias reglas, flujos y configuraciones.
El negocio no vive en una pantalla
El caso anterior revela una confusión que aparece incluso en proyectos bien organizados.
En Discovery se observa cómo trabaja una persona: formularios, campos, botones, estados y recorridos. Después se documentan historias de usuario, criterios de aceptación y excepciones. Todo eso es útil; el problema aparece cuando la pantalla se toma como representación completa del comportamiento que necesita el negocio.
En el caso, la pantalla contiene un campo obligatorio. La necesidad que intenta satisfacer puede formularse de otra manera:
Finanzas necesita conocer el motivo comercial de cada descuento para evaluar si respeta la política y para auditarlo después.
Esa necesidad todavía no dice que el campo deba ser obligatorio en todos los casos, ni que el layout sea el mecanismo adecuado. Falta investigar cuándo se requiere la justificación, quién la aporta, qué excepciones existen y en qué momento del proceso debe estar disponible.
Ese trabajo ya lo conoces. En la Guía N.º 02 separaste petición, síntoma, problema y necesidad, y viste que BABOK distingue la necesidad del requisito que la expresa. Esta entrega añade el siguiente par de conceptos de IIBA.
IIBA diferencia los requisitos, que representan necesidades, de los diseños, que representan soluciones. Ambos se relacionan y evolucionan juntos, pero cumplen funciones distintas. Una pantalla puede ser una excelente representación de una solución; no contiene necesariamente todas las condiciones que deben cumplirse para satisfacer la necesidad.
La Serie 01 citaba la BABOK Guide v3. Esta serie cita también The Business Analysis Standard de IIBA, que resume los fundamentos de la disciplina. IIBA indica que las seis áreas de conocimiento y las 30 tareas de BABOK siguen siendo las mismas, por lo que ambas referencias son coherentes.
Cinco elementos que conviene distinguir
| Elemento | Qué es | En el caso |
|---|---|---|
| Capacidad | Qué necesita poder hacer la organización para obtener un resultado. Equivale a la «capacidad necesaria» de la Guía N.º 02. | Gestionar autorizaciones de descuentos. |
| Proceso | Cómo se desarrolla el trabajo: solicitudes, evaluaciones, decisiones, excepciones y cambios de estado. | Solicitar, justificar, evaluar, aprobar o rechazar, registrar. |
| Operación | Una acción concreta que consulta información, registra una decisión o cambia un estado. | Consultar una solicitud; registrar una aprobación. |
| Experiencia | Cómo una persona o un sistema utiliza la capacidad. La interfaz es un tipo de experiencia, no el único. | CRM, aplicación móvil, herramienta de colaboración. |
| Consumidor | Quién o qué invoca la operación, y en nombre de quién actúa. | Un comercial desde el CRM, la app móvil en nombre de un responsable, un sistema externo o un agente autorizado. |
Son elementos relacionados, pero no equivalentes. Una capacidad no es una API. Un proceso no es una secuencia de pantallas. Y que existan varios consumidores no implica que todos necesiten la misma experiencia.
En esta serie, «experiencia» nombra el concepto general e «interfaz», la pantalla concreta. La separación permite una pregunta útil:
Si retiraras temporalmente la interfaz, ¿podrías seguir describiendo qué necesita conseguir el negocio y bajo qué condiciones?
Si la respuesta es no, probablemente el análisis describe demasiado la solución y demasiado poco el comportamiento esperado.
Una capacidad, varias experiencias
Las organizaciones llevan años integrando aplicaciones, exponiendo servicios y separando componentes. Headless no inventa el desacoplamiento. Tampoco significa que las pantallas desaparezcan ni que todos los procesos necesiten agentes.
En términos generales, una arquitectura Headless separa determinadas capacidades de la experiencia concreta que las presenta o las utiliza.
El concepto es anterior a la IA. Adobe Experience Manager, por ejemplo, documenta modelos en los que el contenido se gestiona y se entrega con independencia de su presentación, y modelos híbridos donde conviven varias formas de integración.
Salesforce presentó Salesforce Headless 360 en TDX, en abril de 2026. El 4 de septiembre de 2026 la denominación pasó a ser AIforce, el nombre que usa ahora Trailhead. El planteamiento es que la lógica, los datos y los permisos de la plataforma puedan utilizarse mediante APIs, herramientas MCP y línea de comandos, también por agentes, sin depender de la interfaz Lightning. Lightning no desaparece: se amplían los lugares desde los que se usa Salesforce.
Las denominaciones comerciales cambian con frecuencia, así que conviene verificarlas en el momento de leer este artículo. La tesis de esta entrega no depende de ellas.
Esa ampliación no es una secuencia obligatoria. Que una capacidad pueda desacoplarse no significa que deba hacerse.
Conceptos que conviene no confundir
| Concepto | Qué aporta | Qué no garantiza |
|---|---|---|
| Interfaz tradicional | Una experiencia integrada para determinadas tareas y usuarios. | Que sus restricciones se apliquen desde otros canales. |
| API | Un mecanismo para intercambiar información o ejecutar operaciones entre sistemas. | Que la operación represente correctamente una capacidad de negocio. |
| Headless | Desacoplamiento entre determinadas capacidades y las experiencias que las utilizan. | Reutilización efectiva, consistencia o menor coste por sí solo. |
| Agente | Capacidad de interpretar objetivos y seleccionar acciones dentro de un alcance definido. | Autorización, decisiones correctas ni autonomía segura. |
Estos elementos pueden coexistir. En el caso, un comercial registra la solicitud en Lightning. La aplicación móvil consulta las solicitudes pendientes mediante un servicio. Una integración puede iniciar una operación de forma determinista. Un agente puede usar herramientas autorizadas para preparar un resumen o proponer una acción.
No todos los consumidores tienen que recibir los mismos datos, disponer de las mismas facultades ni seguir el mismo recorrido. Lo que hay que identificar es qué comportamiento debe permanecer coherente para las ejecuciones sujetas a las mismas condiciones de negocio.
En algunas arquitecturas agénticas, el consumidor elige qué herramienta usar a partir de su nombre, su descripción y el contexto disponible. El propio Trailhead advierte que un agente no ve la capa visual de la interfaz: interpreta etiquetas, descripciones y valores de las listas de selección.
En esos escenarios, las descripciones de capacidades, operaciones y campos ganan peso, porque pueden influir en qué acción se selecciona. No se convierten en reglas de negocio, pero obligan a cuidar la claridad de sus significados, condiciones y límites.
La variedad de consumidores ya existía antes de los agentes. Lo que se amplía son algunas formas en que esos consumidores descubren, interpretan y utilizan las operaciones.
Qué debe mantenerse y qué puede adaptarse
Este es el núcleo de la entrega: separar las condiciones que no dependen del canal de las que pueden cambiar con él, y comprobar dónde se garantiza cada una.
Invariantes
En esta serie llamaremos invariantes a las condiciones que deben conservarse para que una ejecución sea válida dentro de un contexto de negocio determinado.
- Reglas de elegibilidad.
- Límites de autorización.
- Transiciones válidas de estado.
- Condiciones de aprobación.
- Evidencia mínima requerida.
- Resultados que no deben producirse dos veces para una misma operación lógica.
- La información que un error debe transmitir: qué condición no se cumplió y qué puede hacerse.
Variantes
Las variantes son los aspectos que pueden cambiar según la experiencia sin alterar las condiciones que corresponde preservar.
- La forma de solicitar información.
- El orden en que se presentan los datos.
- Los componentes visuales o conversacionales.
- Los mecanismos de ayuda.
- La presentación de una confirmación.
- La forma de mostrar un error y las alternativas al usuario.
No todos los invariantes son universales. Una organización puede tener reglas distintas por país, producto, rol o segmento. Por eso un invariante siempre va vinculado a un contexto y a unas condiciones de aplicación.
Una aplicación móvil puede pedir la información paso a paso. Un portal puede mostrarla en un formulario completo. Una conversación puede pedir aclaraciones cuando faltan datos. Esas diferencias mejoran cada experiencia sin comprometer el resultado compartido.
Los errores marcan bien la frontera. Cómo se muestra un error es una variante. Lo que el error debe comunicar es un invariante: cuando no hay pantalla que lo enseñe, el mensaje es lo único que permite a otro consumidor entender qué falló y cómo corregirlo.
Aplicado al caso
| Lo que debe mantenerse | Lo que puede adaptarse |
|---|---|
| El descuento respeta la política aplicable. | Cómo se presenta la política al solicitante. |
| La solicitud incluye una justificación comercial. | Si se pide en un campo, en una pregunta o en un paso guiado. |
| La aprobación requiere una autorización válida. | Cómo se solicita y comunica la confirmación. |
| La decisión queda registrada con su contexto. | Cómo muestra cada canal el historial. |
| Una solicitud ya procesada no genera otra decisión por un reenvío. | Cómo se informa de que la solicitud ya fue procesada. |
Esta distinción no pretende crear un estándar nuevo de Business Analysis. Aplica técnicas que BABOK ya describe: análisis de reglas de negocio, modelado de procesos y de estados, y la distinción entre requisitos y diseños. La propuesta de Entre Líneas es usarla para descubrir decisiones que podrían estar escondidas en una experiencia.
Dónde se garantiza cada condición
Identificar una condición no basta. Hacen falta dos preguntas distintas:
¿Qué debe cumplirse para que la operación sea válida?
¿Dónde se garantiza hoy ese cumplimiento y cómo se comprueba?
La primera pertenece al acuerdo sobre el comportamiento del negocio. La segunda conecta ese acuerdo con el diseño y la validación de la solución, y se responde junto con arquitectura, desarrollo, seguridad y QA.
Aplicada al caso, la segunda pregunta produce una tabla como esta. Los mecanismos son hipótesis que cada equipo debe verificar en su propia organización, no una descripción del comportamiento de Salesforce.
| Invariante | Dónde podría garantizarse hoy (hipótesis a verificar) | Cómo comprobarlo desde otra ruta |
|---|---|---|
| La solicitud incluye una justificación comercial. | Solo en el Page Layout, o también en la definición del campo o en una regla de validación. | Crear una solicitud sin justificación desde la API y comprobar si se rechaza. |
| El descuento respeta la política aplicable. | Una regla de validación, la lógica de un flujo o solo la revisión manual del aprobador. | Enviar desde otro canal un descuento fuera de política y observar qué ocurre. |
| La aprobación requiere una autorización válida. | El proceso de aprobación, los permisos del usuario o solo la visibilidad de un botón. | Intentar aprobar desde la app móvil con un usuario sin facultad de aprobación. |
| La decisión queda registrada con su contexto. | El historial del registro, un registro de auditoría o nada fuera del CRM. | Aprobar desde la herramienta de colaboración y revisar qué queda registrado. |
| Un reenvío no genera otra decisión. | Un control en la propia operación, o ningún control. | Enviar dos veces la misma petición desde la API. |
Cada fila puede terminar de tres maneras: la condición ya está protegida en todas las rutas, solo lo está en una interfaz, o nadie sabe dónde se garantiza. Las tres son información útil para el análisis.
Una regla compartida no exige concentrar toda la lógica en un único componente técnico. Exige decidir y verificar cómo se cumple en las rutas relevantes.
No todo necesita Headless
Una de las decisiones más valiosas del Business Analyst puede ser concluir que una arquitectura nueva no aporta suficiente valor.
Vuelve al caso. Hoy todo el trabajo de descuentos ocurre en el CRM. El equipo comercial propone que los responsables también puedan aprobar desde una aplicación móvil y desde una herramienta de colaboración.
Antes de recomendar una solución, conviene separar cuatro decisiones. Se toman por separado y pueden combinarse.
La experiencia
¿Dónde necesita trabajar realmente cada persona?
Quizá los responsables comerciales necesiten consultar solicitudes cuando están fuera de la oficina. Quizá Finanzas siga necesitando una interfaz completa para revisar excepciones. Añadir una experiencia no obliga a sustituir las actuales.
La exposición
¿Qué comportamiento debe estar disponible para otros consumidores?
Consultar una solicitud no tiene el mismo riesgo que aprobarla. «Cambiar el campo Estado a Aprobado» y «registrar una aprobación autorizada con su justificación» no son lo mismo.
La ejecución
¿La operación puede resolverse con reglas deterministas?
Si la política ya establece condiciones claras, una operación convencional puede bastar. Un agente puede interpretar solicitudes ambiguas o preparar recomendaciones, sin autonomía para aprobar. Esa autonomía tendrá su propia investigación en la serie.
La gobernanza
¿Quién puede solicitar, recomendar y aprobar?
¿Quién responde cuando una autorización se ejecuta mal? ¿Qué evidencia debe quedar registrada? Estas preguntas no desaparecen al incorporar una API o un agente, ni se resuelven porque una herramienta esté disponible.
Comparar antes de decidir
En la Guía N.º 03 comparaste alternativas por valor, esfuerzo, riesgo, tiempo hasta valor y adopción, e incluiste la opción de no cambiar. Aquí se aplica el mismo criterio a las decisiones de experiencia, exposición y ejecución:
| Alternativa | Cuándo podría ser razonable | Qué habría que validar |
|---|---|---|
| Mantener la experiencia actual | Los responsables ya aprueban a tiempo y no hay otra necesidad justificada. | Fricciones reales, tiempo de aprobación y coste de no cambiar. |
| Mejorar la solución nativa | Las dificultades están en el proceso, la navegación o la configuración actual. La app móvil de Salesforce ya permite usar la interfaz estándar desde el teléfono. | Alcance de las reglas, adopción y limitaciones. |
| Exponer operaciones a otros consumidores | Hay necesidades reales de acceso desde otras aplicaciones o procesos. | Contratos de las operaciones, permisos, versiones, soporte y coste. |
| Incorporar asistencia agéntica | Interpretar y seleccionar acciones aporta valor frente a alternativas más simples. | Supervisión, seguridad, evaluación y coste operativo. |
Headless también añade trabajo: gestión de contratos, pruebas entre consumidores, observabilidad, versionado, soporte y gobierno. Los modelos de consumo, las licencias y las políticas de uso de la plataforma también pesan. Salesforce, por ejemplo, publicó en septiembre de 2026 que prevé introducir en noviembre el registro de agentes externos y un nuevo modelo de facturación asociado. A la fecha de consulta es una previsión, no una funcionalidad vigente.
Una capacidad tecnológica disponible no es un caso de negocio aprobado.
- Dirección preferidaOfrecer a los responsables una operación de consulta de solicitudes desde la app móvil o la herramienta de colaboración, y mantener la aprobación en el mecanismo actual.
- Siguiente paso, si se validaExponer una operación específica para registrar una decisión autorizada, no la actualización directa del registro.
- Fuera de alcanceLa aprobación por un agente. Un agente podría preparar resúmenes de solicitudes, sin facultad para decidir.
- CondicionesQue los invariantes del movimiento 04 se cumplan desde la nueva ruta, que los permisos de cada consumidor estén definidos, que el coste de plataforma y licencias sea asumible y que los responsables adopten el nuevo canal.
- Si no se cumplenMejorar la solución nativa pasa a ser la recomendación definitiva.
La pregunta no es si se puede desacoplar una funcionalidad. Es si hacerlo resuelve una necesidad que justifica sus costes y responsabilidades.
Qué cambia en tu próximo Discovery
Sería fácil concluir que el Business Analyst necesita una metodología nueva. La investigación no muestra eso.
Los fundamentos siguen siendo los mismos: comprender necesidades, analizar procesos, identificar stakeholders, definir requisitos, evaluar soluciones y comprobar resultados. Lo que cambia es la atención que merecen algunas preguntas cuando una capacidad puede utilizarse desde varias experiencias.
Antes, una conversación de análisis podía terminar con la descripción detallada de una pantalla y sus criterios. Ahora conviene comprobar si esa descripción basta para todos los consumidores relevantes.
Cinco preguntas para incorporar
- 1¿Qué resultado de negocio hay que garantizar?No empieces por la pantalla que hay que construir ni por la API que alguien propone. Identifica la capacidad y las condiciones necesarias para el resultado.
- 2¿Quién o qué puede utilizar esa capacidad, y en nombre de quién?Incluye aplicaciones, integraciones, procesos automatizados y agentes cuando sean consumidores reales o razonablemente previstos. No todos tendrán los mismos permisos ni las mismas necesidades.
- 3¿Qué condiciones deben mantenerse coherentes?Identifica las reglas, decisiones, estados, autorizaciones, resultados y mensajes de error que no deberían depender por accidente de una experiencia.
- 4¿Qué puede cambiar según el canal?Una app móvil, un portal y una conversación no necesitan presentar la información igual. Distingue las adaptaciones legítimas de las diferencias que comprometen una regla.
- 5¿Dónde se cumple hoy cada condición y cómo la verificarías desde otra ruta?Es la pregunta más incómoda. Puede descubrirse que una regla vive solo en una pantalla, o que ya está protegida por mecanismos compartidos. Ambos resultados son válidos; la diferencia es que ahora se sabe.
Las tres preguntas del inicio, respondidas
El movimiento 01 dejó abiertas tres preguntas sobre la justificación obligatoria. Con el análisis completo, el caso permite responderlas. Son respuestas dentro del caso hipotético: la tercera se apoya en una premisa fijada en el movimiento 01, no en la inspección de una organización real.
| Pregunta del movimiento 01 | Respuesta en el caso |
|---|---|
| ¿Condición del negocio o necesidad de una experiencia? | Del negocio: Finanzas necesita el motivo para evaluar y auditar cada descuento (movimiento 02). |
| ¿En qué rutas debe cumplirse? | En todas las que crean o aprueban solicitudes, incluidas la app móvil y la herramienta de colaboración (movimiento 04). |
| ¿Qué la garantiza hoy y cómo se comprobó? | Por premisa del caso, solo el Page Layout, y solo se probó desde esa pantalla. En una organización real, esta respuesta exige inspeccionar la configuración antes de afirmarla. Antes de abrir canales nuevos hay que verificarla desde la API (movimiento 04). |
De la condición a la prueba: una columna más
En la Guía N.º 04 construiste una matriz de trazabilidad que unía historia, criterio y escenario de UAT. Cuando una capacidad tiene varios consumidores, esa matriz necesita una columna más: la ruta desde la que se prueba.
| ID | Criterio | Ruta o consumidor | Escenario de prueba | Resultado esperado | Estado |
|---|---|---|---|---|---|
| HU-D01 | Dada una solicitud sin justificación, cuando se intenta guardar, entonces se rechaza con un mensaje que indica qué falta. | CRM (Lightning) | Un comercial guarda una solicitud sin justificación desde la ficha. | La solicitud no se guarda y el mensaje indica que falta la justificación. | Pendiente / Aprobado / Rechazado |
| HU-D01 | El mismo criterio. | API (app móvil) | La integración envía una solicitud sin justificación. | La operación se rechaza y la respuesta indica que falta la justificación. | Pendiente / Aprobado / Rechazado |
| HU-D02 | Dado un usuario sin facultad de aprobación, cuando intenta aprobar, entonces la operación se rechaza. | Herramienta de colaboración | Un usuario sin facultad intenta aprobar desde el canal de colaboración. | La aprobación no se registra y la solicitud conserva su estado anterior. | Pendiente / Aprobado / Rechazado |
Como en la Guía N.º 04, el resultado esperado se fija antes de probar y el estado se completa al ejecutar la prueba. Si el resultado obtenido no coincide con el esperado, el estado es «Rechazado» y la diferencia queda documentada como evidencia.
Un criterio probado solo desde la pantalla deja sin cubrir justo las rutas por las que reaparecería el problema del movimiento 01.
Elige una operación de tu organización: aprobar una solicitud, modificar un pedido, registrar una devolución o actualizar una oportunidad. No necesitas construir una integración ni configurar un agente. Describe:
- El resultado que debe producir la operación.
- Los consumidores que pueden ejecutarla y en nombre de quién actúan.
- Las condiciones de negocio comunes.
- Las diferencias legítimas entre experiencias.
- El mecanismo que garantiza hoy cada condición y la evidencia con la que lo comprobarías desde otra ruta.
Si no puedes responder alguna, has encontrado un punto que merece investigación. No necesariamente un defecto técnico ni una mala implementación.
Un supuesto que necesita hacerse explícito antes de seguir construyendo.