Hoy escribí en LinkedIn sobre ese senior que, en lugar de hacértelo notar, se sentó a enseñarte. Me quedé pensando en qué hace falta para que eso pase seguido y no por casualidad. Esto es lo que ordenaría en las primeras semanas de alguien que se suma al equipo.

1. Un sandbox propio desde el primer día

Se aprende tocando. Y nadie toca tranquilo si cada prueba es en producción.

En Setup > Sandboxes se crea un sandbox Developer para la persona nueva. Copia la configuración de la org (objetos, campos, flujos, reglas) sin los datos de producción, así que puede romper lo que quiera. Si necesita datos reales de muestra para entender un proceso, un sandbox Partial Copy trae una parte según una plantilla.

El primer ejercicio que le daría: recorrer en el sandbox el proceso más usado de la empresa, de punta a punta, y anotar cada cosa que no entiende. Esa lista es el temario de la primera charla con el senior.

2. Un senior de referencia, con tiempo en la agenda

Si enseñar se hace en los ratos libres, no se hace. Reservaría un bloque fijo por semana en la agenda del senior, visible para todos, que cuente como trabajo.

En esas charlas, lo que más rinde es que el senior explique por qué está armado así, no solo cómo se usa. El cómo se encuentra en la documentación. El porqué casi nunca está escrito.

3. Lo que se explica dos veces, se escribe donde se usa

Si el senior explica lo mismo por segunda vez, es una señal de que falta algo escrito. Y lo mejor es escribirlo en el lugar donde la persona lo va a necesitar:

Si el ERP vive en la misma org, como EGA Futura ERP, los procedimientos internos pueden ir en EGA Futura Clarity, donde un artículo de conocimiento se enlaza a un ticket de servicio o a una tarea de proyecto. Quien hace el trabajo lo encuentra sin salir de la pantalla.

4. Un lugar para preguntar sin castigo

La persona nueva tiene que poder decir "no entiendo" sin sentirse menos. Ayuda que haya un lugar acordado para preguntar, y que el senior conteste ahí y no por privado, así la respuesta le queda al próximo.

En Salesforce sirve un grupo de Chatter del equipo. En la Plataforma EGA Futura es EGA Futura Habitat, donde la conversación queda sobre el registro del que se habla. Una pregunta sobre un pedido queda en ese pedido.

5. Festejar cuando resuelve solo

Parece menor y no lo es. Cuando la persona nueva resuelve algo por su cuenta, y sobre todo si encontró una forma mejor que la que usaba el equipo, que se note. Ese es el momento en el que el senior hizo bien su trabajo.

Para seguir aprendiendo afuera del equipo

Todos los jueves hay clases de Salesforce en vivo y gratis para administradores y desarrolladores, y los cursos de la Plataforma EGA Futura están ordenados de principiante a intermedio.

La parte humana de este tema, la del senior que se sienta a enseñar y la del que se guarda todo, la desarrollé en EGA Futura Discover.

Juan Manuel Garrido, EGA Futura (ERP nativo en Salesforce).

El contexto de negocio está en Discover: por qué seguimos pidiendo los números en Excel con CRM, ERP e IA. Acá van las consultas para encontrar esos rastros con datos, antes de hablar con el equipo.

Los objetos son estándar: ProcessInstance (cada vez que un registro entra a un proceso de aprobación), ProcessInstanceStep (cada paso resuelto) y ProcessInstanceWorkitem (lo que está pendiente). Uso Opportunity como ejemplo; si tu circuito aprueba pedidos o cotizaciones, cambiá el objeto.

1. Qué está pendiente hace más de dos días

SELECT ProcessInstance.TargetObject.Name, Actor.Name, CreatedDate, ElapsedTimeInHours
FROM ProcessInstanceWorkitem
WHERE CreatedDate < LAST_N_DAYS:2
ORDER BY CreatedDate ASC

Un pendiente viejo puede querer decir que la persona asignada no es la que decide. Mientras tanto, alguien ya consiguió el OK por otro lado y el registro quedó esperando.

2. Aprobaciones que se resolvieron en minutos

SELECT TargetObject.Name, Status, CreatedDate, CompletedDate, ElapsedTimeInMinutes
FROM ProcessInstance
WHERE Status = 'Approved' AND CreatedDate = LAST_N_DAYS:90

Exportá el resultado y ordená por ElapsedTimeInMinutes. Una aprobación de un minuto no es mala en sí misma. Pero si se repite siempre con el mismo aprobador, es probable que la decisión se haya tomado antes, por otro canal, y que el sistema solo la registre.

3. Quién aprobó y quién estaba asignado

SELECT ProcessInstance.TargetObject.Name, StepStatus, Actor.Name, OriginalActor.Name, Comments, CreatedDate
FROM ProcessInstanceStep
WHERE StepStatus IN ('Approved','Rejected') AND CreatedDate = LAST_N_DAYS:90

SOQL no compara dos campos entre sí, así que filtrá en la planilla las filas donde Actor y OriginalActor son distintos. Ahí están las reasignaciones y las delegaciones. Si son muchas, la regla del sistema no coincide con quién decide en la práctica.

Mirá también la columna Comments. Muchas aprobaciones sin comentario, de alguien que casi nunca entra a Salesforce, suelen ser un OK que llegó por otro lado.

4. Registros que debían pasar por aprobación y no pasaron

SELECT Id, Name, Descuento__c, (SELECT Id, Status FROM ProcessInstances)
FROM Opportunity
WHERE Descuento__c > 15 AND CloseDate = LAST_N_DAYS:90

Descuento__c y el 15 son un ejemplo: poné el campo y el umbral de tu regla. Las filas con la subconsulta vacía cumplen la condición y nunca entraron al proceso. O la regla no se aplica, o alguien lo resolvió por fuera.

5. Descuentos que cambiaron después del OK

Si el campo tiene historial activado:

SELECT OpportunityId, OldValue, NewValue, CreatedDate, CreatedBy.Name
FROM OpportunityFieldHistory
WHERE Field = 'Descuento__c' AND CreatedDate = LAST_N_DAYS:90
ORDER BY OpportunityId, CreatedDate

Cruzalo con CompletedDate de la consulta 2. Un cambio de descuento posterior a la aprobación es justo el caso que el circuito debía evitar.

Qué hacer con los resultados

Las consultas no dicen por qué. Dicen a quién preguntarle:

Para el diseño del circuito, con la prueba del aprobador de vacaciones, está quién aprueba un descuento cuando el gerente está de vacaciones.

Si el ERP vive en la misma org, como EGA Futura ERP, estas consultas cubren también aprobaciones de pedidos, compras o notas de crédito, porque están en la misma base. Y antes de poner un agente de IA a aprobar, estas cinco señales te dicen si el circuito que va a seguir es el real.

Juan Manuel Garrido, EGA Futura (ERP nativo en Salesforce).

Son puntos de partida. Los nombres de objetos son estándar de Salesforce; si tu ERP guarda pedidos o facturas en objetos propios, cambiá Order por el objeto que corresponda.

1. Quién entra y quién no

SELECT Name, Profile.Name, LastLoginDate
FROM User
WHERE IsActive = true
AND (LastLoginDate < LAST_N_DAYS:14 OR LastLoginDate = null)
ORDER BY LastLoginDate ASC NULLS FIRST

Un usuario activo que no entra hace dos semanas está trabajando en otro lado. No es una acusación: es la primera persona con la que conviene hablar.

2. Quién carga los pedidos

SELECT CreatedBy.Name, COUNT(Id) pedidos
FROM Order
WHERE CreatedDate = LAST_N_DAYS:30
GROUP BY CreatedBy.Name
ORDER BY COUNT(Id) DESC

Si diez vendedores venden y dos personas cargan casi todos los pedidos, hay una planilla en el medio. Alguien junta lo que le mandan y lo pasa al sistema.

3. Qué campos nadie completa

COUNT(campo) cuenta solo los registros donde el campo tiene valor, así que comparar contra COUNT(Id) da el porcentaje de llenado:

SELECT COUNT(Id) total, COUNT(PoNumber) con_oc, COUNT(Campo_Personalizado__c) con_campo
FROM Order
WHERE CreatedDate = LAST_N_DAYS:90

Campo_Personalizado__c es un ejemplo: reemplázalo por los campos que el vendedor ve al cargar. No todos los tipos de campo admiten COUNT(campo) (por ejemplo, áreas de texto largo); para esos, usá un reporte con filtro "no está vacío". Un campo obligatorio con llenado del 100% no dice nada; un campo opcional casi vacío que alguien pidió "ya que estamos" es candidato a salir del layout.

4. Qué personalizaciones hay en el objeto

Con Tooling API (por ejemplo desde Developer Console, tildando "Use Tooling API"):

SELECT DeveloperName, CreatedDate, LastModifiedDate
FROM CustomField
WHERE TableEnumOrId = 'Order'
ORDER BY CreatedDate

Cruza esta lista con la consulta 3. Los campos creados para copiar el sistema anterior y que casi nadie completa son los que más pesan cuando hay que cambiar algo.

5. Qué quedó duplicado de la migración

SELECT Name, COUNT(Id) cantidad
FROM Account
GROUP BY Name
HAVING COUNT(Id) > 1
ORDER BY COUNT(Id) DESC

Es una búsqueda gruesa: dos cuentas pueden llamarse igual y ser distintas, y dos duplicados pueden tener nombres apenas diferentes. Para lo segundo están las Matching Rules y Duplicate Rules de Salesforce. Pero como primera foto alcanza para ver si "lo limpiamos después" sigue pendiente.

Qué hacer con los resultados

Las consultas no reemplazan la charla con el equipo. La ordenan:

Si tu ERP es nativo de Salesforce, como EGA Futura ERP, estas consultas cubren también pedidos, facturas y cobranzas, porque viven en la misma base que el CRM. Si el ERP está afuera, vas a necesitar repetirlas en cada sistema, y esa diferencia ya es un dato.

Juan Manuel Garrido, fundador de EGA Futura.

1. Qué es una planilla puente

Una planilla puente es cualquier archivo, mensaje o carga manual que existe solo para mover un dato de un sistema a otro. Las más comunes:

• El Excel que cruza oportunidades ganadas con facturas emitidas.
• El pedido que llega por WhatsApp y alguien carga en el CRM y después en el ERP.
• La factura de proveedor que alguien tipea a partir de un PDF.
• El reporte que se arma antes de una reunión porque ningún sistema tiene el número completo.

Si no las listas, un agente de IA va a terminar leyendo las mismas fuentes que no coinciden.

2. Una fila por cada dato que viaja

Recorre con cada área una semana normal y completa una fila por cada dato que pasa de un lugar a otro:

Los valores son un ejemplo de formato, no un caso real. Las columnas que más dicen son "Cómo viaja hoy" y "Clave para cruzar": si no hay clave común, la conciliación depende del criterio de una persona.

3. Definir qué significa cada número

Buena parte de la reunión de los cuatro números es un problema de definición. "Vendido" puede querer decir cosas distintas en Salesforce:

-- Vendido como oportunidad ganada en el mes
SELECT SUM(Amount) FROM Opportunity
WHERE IsWon = true AND CloseDate = THIS_MONTH

-- Vendido como pedido activado en el mes
SELECT SUM(TotalAmount) FROM Order
WHERE Status = 'Activated' AND EffectiveDate = THIS_MONTH

Las dos consultas son válidas y pueden dar números distintos el mismo día. Y "facturado" vive en otro lado, en el ERP. Antes de automatizar, cada área tiene que acordar qué consulta responde la pregunta de dirección.

4. Clasificar cada fila en tres grupos

Con el inventario completo, cada fila cae en uno de estos grupos:

1. Desaparece con una base única. Si ventas, facturación y stock comparten la misma base de datos que el CRM, el Excel que cruza oportunidades con facturas deja de hacer falta. Es el caso de un ERP nativo de Salesforce como EGA Futura ERP.
2. Lo puede tomar un agente de IA. Entradas que hoy alguien tipea: pedidos por WhatsApp, facturas u órdenes de compra en PDF, preguntas sobre los datos que terminan en otro Excel.
3. Necesita una decisión de negocio. Cuál es la definición oficial de "vendido", quién es dueño de cada dato, qué área corrige un error. Ningún agente resuelve esto configurando nada.

El orden importa. Si pones un agente sobre filas del grupo 3 sin resolverlas, automatizás la discusión.

5. Qué mirar después

Con el inventario hecho, revisa tres señales cada mes:

• Cuántas filas siguen viajando por Excel o carga doble.
• Cuántas preguntas de dirección se contestan con una consulta y no con una planilla.
• Cuánto tiempo pasa entre que entra un pedido y aparece registrado en el sistema.

Si las tres mejoran, el agente está trabajando sobre algo firme.

Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate.

1. Elegir la operación correcta

No sirve el caso ideal. Elige una venta reciente que haya tenido al menos una excepción: entrega parcial, descuento fuera de lista, nota de crédito o cobro en varias partes. Las excepciones son las que después aparecen como "eso no estaba contemplado".

2. Registrar cada paso con la misma plantilla

Recorre la venta con quien la hizo y completa una fila por paso:

Los valores de la tabla son un ejemplo de formato, no un caso real. Lo que importa son las dos últimas columnas: ahí está el trabajo que nadie presupuesta.

3. Ubicar cada paso en Salesforce

Con la tabla completa, cada paso se puede ubicar en el modelo de datos:

• Cliente y contactos: Account y Contact.
• Oportunidad y cotización: Opportunity, y Quote con sus Quote Line Items si la empresa cotiza formalmente. Quotes se habilita en Setup.
• Pedido: Order y Order Product. Orders también se habilita en Setup, y conviene definir qué estados de Order usa la empresa y quién puede activar un pedido.
• Precios: Price Book y Price Book Entry. Si hay listas por cliente o canal, se ve acá.
• Aprobaciones: Approval Processes o aprobaciones construidas con Flow. Toda aprobación que hoy vive en WhatsApp tiene que tener un criterio escrito (monto, porcentaje, rol) y un suplente para cuando el aprobador no está.
• Entrega, factura, nota de crédito y cobro: Sales Cloud no trae objetos estándar para facturación, notas de crédito ni cobranzas. Esa parte la cubre una aplicación nativa (un ERP sobre Salesforce, como el de EGA Futura), otro producto de Salesforce o una integración con el sistema contable. Esa decisión cambia el presupuesto y conviene tomarla antes de firmar.

4. Clasificar cada brecha

Cada cosa que no entra limpia en el mapa va a una de cuatro categorías:

1. Estándar: lo resuelve la plataforma o la aplicación tal como viene.
2. Configuración: campos, listas de valores, reglas de validación, Flows declarativos, permisos.
3. Desarrollo: Apex, componentes Lightning, integraciones. Necesita estimación propia.
4. Decisión de negocio: nadie definió la regla. Ejemplo: quién autoriza una nota de crédito por encima de cierto monto. No se presupuesta como horas de consultoría; se resuelve en una reunión con alguien que tenga autoridad.

La cuarta categoría es la que más pesa. Si se mezcla con las otras tres, termina como adicional, como fecha que se corre o como planilla que sobrevive a la salida en producción.

5. Revisar las planillas una por una

Por cada Excel que aparezca en la columna "Fuera del sistema", anota qué calcula, de dónde saca los datos y quién lo usa para decidir. Muchas veces se convierte en un campo fórmula, un roll-up o un informe. Otras veces esconde una regla de negocio que nadie había escrito. En los dos casos, tiene que estar en el alcance.

6. Con qué salir de la reunión

• La tabla del recorrido, validada por quienes hacen el trabajo.
• El mapa de pasos a objetos y aplicaciones.
• La lista de brechas clasificada en las cuatro categorías.
• Las decisiones de negocio pendientes, cada una con un responsable.

Con eso se puede hablar de alcance, equipo, presupuesto y fechas con criterio. Y unas semanas después de salir en producción, la misma tabla sirve para comprobar si la columna "Fuera del sistema" quedó vacía.

Juan Manuel Garrido

Esta nota es la parte técnica de algo que planteé en Discover: por qué un agente de IA que se arma en 20 minutos tarda meses en funcionar dentro de Salesforce. Acá me concentro en qué pasa cuando el agente hace un update y en cómo diseñar la herramienta para que no escriba a ciegas.

El agente no se salta el orden de ejecución

Para Salesforce, un update que llega desde un agente es un update más. Pasa por el orden de ejecución de triggers y automatizaciones. Resumido:

1. Se cargan los valores y corren las validaciones de sistema.
2. Corren los Flows before-save (record-triggered, rápidos, sin DML).
3. Corren los triggers before de Apex.
4. Corren las Validation Rules custom y las reglas de duplicados.
5. Se guarda el registro, todavía sin commit.
6. Corren los triggers after.
7. Corren assignment rules, auto-response y Workflow Rules. Si una Workflow Rule actualiza un campo, los triggers before y after de update se ejecutan una vez más.
8. Corren procesos de Process Builder y Flows after-save.
9. Se recalculan roll-up summaries y sharing, y recién ahí se hace commit.
10. Después del commit salen mails y lógica asíncrona.

Un registro con 4 Validation Rules, 3 Flows y un trigger de Apex que nadie se anima a tocar no es raro. Cada paso puede rechazar el cambio, modificar otros campos o crear registros nuevos. El agente no ve nada de esto. Solo recibe un éxito o un mensaje de error.

Qué cambia cuando son 500 registros

Si le pides al agente actualizar los precios de 500 productos, aparecen cosas que en la demo no existen:

• Los triggers procesan registros en bloques de hasta 200. Un trigger que no está bulkificado puede chocar con los límites de transacción, como las 100 consultas SOQL sincrónicas o las 150 sentencias DML.
• Con allOrNone en true, un solo registro rechazado tira abajo el lote entero. Con false, el lote queda a medias y alguien tiene que saber cuáles pasaron.
• Una Validation Rule puede rechazar algunos registros y otros no, según sus datos.
• Un Flow after-save puede disparar cambios en objetos relacionados que el agente nunca pidió.

Y lo peor no es técnico. El agente puede hacer exactamente lo que le pediste, pero si nadie contempló que esos precios estaban asociados a contratos vigentes, la org queda consistente y el negocio queda mal.

Darle al agente una acción, no acceso libre al DML

La alternativa a "el agente actualiza lo que quiera" es exponerle una acción acotada. En Salesforce eso puede ser un Flow autolanzado o un método de Apex con @InvocableMethod, que después se registra como acción del agente. La lógica de negocio queda en código revisado y probado, y el modelo solo decide cuándo llamarla.

Este ejemplo simula por defecto y solo escribe cuando se pide de forma explícita. Corre en modo usuario para respetar permisos de objeto y de campo, y devuelve el resultado de cada registro en el mismo orden en que llegó:

public with sharing class ActualizarPreciosAccion {

    public class Solicitud {
        @InvocableVariable(required=true label='PricebookEntry Id')
        public Id pricebookEntryId;
        @InvocableVariable(required=true label='Nuevo precio')
        public Decimal nuevoPrecio;
        @InvocableVariable(label='Aplicar cambio (false = solo simular)')
        public Boolean aplicar;
    }

    public class Resultado {
        @InvocableVariable public Id pricebookEntryId;
        @InvocableVariable public String estado;
        @InvocableVariable public String mensaje;
    }

    @InvocableMethod(label='Actualizar precios con control'
        description='Simula o aplica cambios de precio y devuelve el estado de cada registro')
    public static List<Resultado> ejecutar(List<Solicitud> solicitudes) {
        List<Resultado> resultados = new List<Resultado>();
        List<PricebookEntry> aActualizar = new List<PricebookEntry>();
        List<Integer> posiciones = new List<Integer>();

        for (Integer i = 0; i < solicitudes.size(); i++) {
            Solicitud s = solicitudes[i];
            Resultado r = new Resultado();
            r.pricebookEntryId = s.pricebookEntryId;
            r.estado = 'SIMULADO';
            r.mensaje = 'Precio propuesto: ' + s.nuevoPrecio;
            resultados.add(r);

            if (s.aplicar == true) {
                aActualizar.add(new PricebookEntry(
                    Id = s.pricebookEntryId,
                    UnitPrice = s.nuevoPrecio
                ));
                posiciones.add(i);
            }
        }

        if (!aActualizar.isEmpty()) {
            Database.SaveResult[] srs =
                Database.update(aActualizar, false, AccessLevel.USER_MODE);
            for (Integer j = 0; j < srs.size(); j++) {
                Resultado r = resultados[posiciones[j]];
                if (srs[j].isSuccess()) {
                    r.estado = 'ACTUALIZADO';
                    r.mensaje = null;
                } else {
                    r.estado = 'RECHAZADO';
                    r.mensaje = srs[j].getErrors()[0].getMessage();
                }
            }
        }
        return resultados;
    }
}

Algunas decisiones de diseño:

• Simular por defecto. Si el campo aplicar viene vacío, no se escribe nada. El agente primero muestra qué cambiaría y una persona o una regla confirma.
• allOrNone en false con resultado por registro. El agente puede informar qué pasó y qué quedó rechazado, con el mensaje real de la Validation Rule, en vez de reintentar a ciegas.
• USER_MODE. La acción corre con los permisos del usuario que la ejecuta, no con permisos de sistema.
• Las reglas del negocio van adentro. Si hay que frenar cuando un producto está atado a un contrato vigente, ese chequeo se escribe en la acción según cómo lo modela tu org, no se le pide al modelo que lo deduzca.

Antes de registrar la acción en el agente

• Revisa qué Flows, triggers y Validation Rules tiene cada objeto que la acción toca.
• Prueba la acción con lotes de más de 200 registros en un sandbox con datos parecidos a producción.
• Define con qué usuario corre el agente y qué puede ver y editar.
• Decide quién aprueba las excepciones. Si no hay respuesta, la acción no debería existir todavía.
• Deja fuera del agente lo que una regla resuelve sola. Si la decisión cabe en un if, Flow o Apex la resuelven más rápido, con menos costo y de forma predecible.

El motor del agente puede ser un bucle while. Lo que hace que funcione en una empresa es todo lo que rodea a ese bucle.

Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate. La mirada de negocio sobre este tema está en Discover: qué resolver antes de dejar un agente trabajando en tu empresa.

Cuando una implementación de ERP o CRM se cae, la primera explicación suele ser “el sistema”. En la práctica, lo que falta casi siempre es gobernanza de proceso antes de tocar configuración. Aplica a Salesforce, Oracle o Microsoft.

Inventario mínimo antes de configurar

1. Dueño nombrado por workflow crítico (ventas, stock, facturación, compras, cobranzas), con tiempo real en el proyecto, no solo en el comité de status.
2. Mapa de dependencias entre objetos y procesos: qué dispara qué, y qué dato maestro alimenta cada paso.
3. Modelo de datos acordado antes de la primera pantalla: claves, estados, excepciones, quién escribe cada campo.
4. Estrategia de testing punta a punta, no solo UAT de pantallas sueltas.
5. Plan de capacitación antes del go-live, no después del incendio.

Sin eso, la configuración se hace a las apuradas, las excepciones se esconden y los change requests se vuelven el plan.

Señales tempranas de que el proyecto ya viene torcido

• Estados en verde sin descubrimiento documentado.
• Requerimientos vagos (“que haga lo mismo que hoy”).
• Datos maestros tratados como tarea de última semana.
• El implementador pide acelerar mientras nadie puede explicar el proceso punta a punta.

Por qué el software “falla” en el go-live

Facturas que no cierran, stock inconsistente, pedidos trabados y finanzas que no cierra el mes no son misterios de plataforma. Son el resultado de procesos sin dueño y datos sin gobierno. El ERP o el CRM dejan en evidencia lo que ya estaba roto.

Si tu stack es Salesforce, un ERP nativo evita una capa extra de sincronización, pero no reemplaza el trabajo de descubrimiento. La herramienta no arregla un proceso que nadie lidera.

Qué documentar en la primera semana

• Lista de workflows críticos con dueño y backup.
• Diagrama simple de dependencias (aunque sea en una pizarra).
• Definición de “dato maestro limpio” para clientes, productos y precios.
• Casos de prueba de punta a punta con resultado esperado.
• Criterio de go/no-go que no sea “la demo salió linda”.

Lectura ampliada en EGA Futura Discover.

Qué es el Headless Toolkit?

Antes se llamaba Headless 360 (se presentó en TrailblazerDX). Las tecnologías son las mismas; cambió el nombre.

AIforce o Agentforce?

Cómo cambia el ciclo de desarrollo?

• Diseño: pedirle al agente una solución que siga tus directrices, tecnologías y criterios.
• Revisión: chequear que lo desarrollado sea lo pedido, porque la IA también se equivoca.
• Guardrails: poner conocimiento y límites a lo que el agente puede hacer.

Los skills se escriben en Markdown y se pueden compartir entre compañeros. Para calidad y seguridad del código generado con IA, la receta de Alba: sistema bien montado, skills y directrices claras, y revisión siempre por encima.

MCP en la práctica

En su demo de Data 360, Alba usó el MCP Server de Data 360 y, con un agente, creó DMOs, calculated insights, transforms e índices de búsqueda. Lo usó para configurar la plataforma, no para programar.

Para ver cómo se implementan agentes en una empresa, en Vantegrate explicamos qué son los agentes de IA. Crónica completa en Vantegrate Pulse y versión con FAQ en EGA Futura Discover.

Por qué hace falta un checklist que no es técnico?

Porque la tecnología no resuelve problemas, los deja a la vista. En implementaciones de compañías grandes, medianas y de todo tipo vi empresas crecer con software básico y equipos enormes hundirse con Salesforce o SAP. La diferencia no fue el software: fue la estructura, el plan y la gobernanza.

1. Gobernanza: quién hace qué?

Un error frecuente es asignar la administración al gerente de marketing o de ventas. No es un admin. Tampoco es un project manager. Si quieres ver cómo piensa un administrador, en EGA Futura Discover reunimos 10 preguntas que los administradores deben hacerse primero.

2. Cronograma: cuánto margen sumar?

Regla práctica: al cronograma estimado, súmale un 70% más de tiempo. La experiencia me enseñó que ese margen casi nunca sobra.

3. Capacitación: genérica o a medida?

A medida. Tiene que estar pensada para el equipo que va a usar el sistema, con:

• Sus procesos reales, no los del manual.
• Su idioma.
• Su forma de trabajar.

En EGA Futura armamos los cursos de la Plataforma EGA Futura con ese criterio.

4. Datos: cuándo se limpian?

Antes de migrar. La frase los limpiamos después aparece en casi todos los proyectos y casi nunca se cumple. Si migras el mismo cliente cargado tres veces, el sistema nuevo va a mostrar tres clientes.

Los tres no negociables

1. Un Project Manager con responsabilidad real sobre el proyecto.
2. Una herramienta para gestionarlo. Nosotros usamos EGA Futura Project, nuestra aplicación de gestión de proyectos.
3. Datos limpios antes de migrar.

Por qué esto importa en un ERP sobre Salesforce?

En nuestro ERP nativo para Salesforce ventas y operación comparten los mismos datos en la misma Org, así que un dato sucio aparece en todas partes. Para practicar, damos clases de Salesforce en vivo y gratis.

La versión completa, con preguntas frecuentes, está en EGA Futura Discover.

Cuál es el escenario de partida?

El cliente pide un 20% de descuento. El vendedor puede autorizar hasta el 15%. El gerente, que es quien aprueba por encima de ese límite, está de vacaciones.

Si el circuito se armó pensando solo en el camino feliz, la oportunidad queda en Pendiente de aprobación y la decisión se busca por fuera del sistema. Un ERP en Salesforce hace visible ese agujero, porque la oportunidad, el pedido y el margen están en la misma Org.

Paso 1: cómo reconstruyo el último caso real?

Antes de abrir Flow Builder, pido la última venta en la que pasó exactamente esto. Con la oportunidad abierta, respondemos tres preguntas y anotamos lo que salga:

Paso 2: qué reglas tengo que dejar escritas?

Del caso real salen tres definiciones. Conviene escribirlas en lenguaje de negocio antes de pensar en la implementación:

1. Hasta dónde decide el vendedor. El límite de descuento que puede aplicar sin pedir permiso.
2. Cuándo interviene Finanzas. El punto a partir del cual el margen pesa más que la urgencia comercial.
3. Quién reemplaza al aprobador. Con nombre o con rol, y desde cuándo.

Recién con esto acordado tiene sentido configurar permisos, reglas y alertas en Salesforce. Si quieres ver las herramientas disponibles, en EGA Futura Discover repasamos las capacidades del proceso de aprobación con Salesforce Flow.

Paso 3: qué datos tiene que capturar el circuito?

Para que la aprobación se pueda auditar después, el registro tiene que guardar, como mínimo:

• Quién autorizó el descuento.
• Por qué lo autorizó, es decir, el motivo de la excepción.
• Con qué política vigente se tomó la decisión.

Y quien aprueba tiene que ver el margen de la operación en la misma pantalla en la que decide.

Paso 4: qué casos de prueba corro?

Este es el set mínimo que corro antes de dar el circuito por terminado. El caso del gerente ausente va primero, porque es donde más circuitos fallan:

Si algún caso falla, la solución casi nunca es un recordatorio más. Es volver a la regla del paso 2.

Por qué esto importa en un ERP?

Porque el descuento sigue vivo después de la venta: impacta en la facturación, el margen y la cobranza. En nuestro ERP nativo para Salesforce el circuito trabaja sobre los mismos datos que usa Finanzas, y el motor de automatización de procesos permite llevar las reglas acordadas al sistema. Para practicar, en EGA Futura damos clases de Salesforce en vivo y gratis.

La versión completa, con preguntas frecuentes, está en EGA Futura Discover.

El escenario

Un Screen Flow para el área de finanzas que muestra cotizaciones de monedas traídas de una API externa. El usuario elige las monedas que le interesan y el Flow sigue trabajando solo con esas. No queremos guardar las cotizaciones en Salesforce: cambian todo el tiempo.

Antes de Winter '26 la Data Table solo aceptaba colecciones de registros, así que la salida típica era un objeto custom espejo, registros temporales o un elemento Transform. Ahora no hace falta.

Paso 1: la clase que define cada fila

Los campos tienen que ser visibles para Flow, por eso van con @AuraEnabled.

public class FxRate {
    @AuraEnabled public String currencyCode;
    @AuraEnabled public String currencyName;
    @AuraEnabled public Decimal buy;
    @AuraEnabled public Decimal sell;
}

Paso 2: la acción invocable

Una acción invocable recibe y devuelve listas, una entrada por cada invocación. Para devolver una colección por invocación, la envolvemos en una clase de resultado.

public with sharing class GetFxRates {
    public class Result {
        @InvocableVariable(label='Rates')
        public List<FxRate> rates;
    }

    @InvocableMethod(label='Get FX Rates')
    public static List<Result> run() {
        Result r = new Result();
        r.rates = FxService.fetchRates(); // tu callout o cálculo
        return new List<Result>{ r };
    }
}

FxService.fetchRates() representa tu lógica: un callout con Named Credential, un cálculo o lo que tengas.

Paso 3: el Flow

1. Creá un Screen Flow y agregá una acción Apex que llame a Get FX Rates.
2. Guardá la salida Rates en una variable de colección de tipo Apex-Defined, clase FxRate. Podés dejar que Flow la cree automáticamente.
3. Agregá una pantalla con el componente Data Table.
4. En Source Collection, elegí esa variable.
5. En Unique Identifier, elegí currencyCode.
6. Configurá columnas (currencyName, buy, sell) y el modo de selección.

Paso 4: usar las filas seleccionadas

La Data Table expone las filas seleccionadas como salida, igual que con registros. Desde ahí podés pasarlas a otra acción de Apex, recorrerlas con un Loop o mostrar un resumen en la pantalla siguiente.

Cómo elegir bien el Unique Identifier

• Tiene que ser único por fila. Si se repite, la selección se vuelve ambigua.
• Preferí un código estable (un recordId, un código de moneda, una clave de negocio) antes que un texto que pueda cambiar.
• Si tu fuente no trae un identificador, generalo en Apex al armar la lista.

Limitaciones a tener en cuenta

• Por ahora es mostrar y seleccionar. La edición inline de celdas con colecciones de Apex sigue pendiente para una próxima release.
• Revisá que el Flow use API 65.0 o superior.
• Si tu caso necesita editar valores dentro de la tabla, por ahora seguí con inputs aparte o con un componente propio.

Dónde lo estamos aplicando

En proyectos sobre Salesforce lo vemos útil para cálculos financieros resueltos en Apex, resultados de procesos batch que no queremos persistir y pantallas internas armadas rápido. Encaja con cómo diseñamos nuestro ERP nativo para Salesforce: usar lo que la plataforma ya resuelve antes de sumar objetos. Si querés ver cómo documentamos estos patrones, están los tutoriales de la Plataforma EGA Futura.

Cierre

No es la feature más vistosa del release, pero saca fricción real entre Apex y la interfaz.

La versión completa, con preguntas frecuentes, está en EGA Futura Discover.

El problema con filtrar solo por certificaciones

Las certificaciones valen. Son un excelente punto de partida y las recomiendo fuertemente. Pero un examen tiene escenarios cerrados. Un proyecto real llega con información incompleta, procesos sin documentar y un sistema que ya tiene historia.

Si usás la certificación como único filtro pasan dos cosas. Dejás afuera a personas con trayectorias no lineales: gente que viene de otro rubro, cambió de camino o aprendió trabajando. Y podés quedarte con alguien que sabe la teoría pero se pierde en el primer problema real.

El ejercicio: un caso real, con información incompleta

La propuesta es sencilla. En lugar de preguntar definiciones, armá un caso basado en un problema que tu equipo ya resolvió. Dejá huecos a propósito. Pedile a la persona que piense en voz alta y que al final escriba qué haría y por qué.

No hace falta que lo resuelva entero. Lo que importa es cómo llega.

Las cinco señales que observar

1. Cómo ordena el problema

Antes de tocar una sola línea de código o de configuración, arma un mapa del problema? Identifica actores, datos y pasos? O salta directo a la herramienta?

2. Qué pregunta cuando falta información

Este es el motivo por el que dejamos huecos. Una persona que pregunta por el volumen de datos, por quién usa el proceso o por qué se hace así hoy, está mostrando criterio. Una que no pregunta nada, asume.

3. Si ve los límites del sistema

En Salesforce hay límites de plataforma, automatizaciones que se pisan y datos que crecen. La pregunta es si la persona ve esos bordes antes de que colapsen, no después.

4. Cómo lo explica por escrito

Pedí un resumen corto al final. Si puede explicar qué hizo y por qué de forma que otra persona lo entienda sin estar en la entrevista, eso vale oro en un equipo distribuido.

5. Qué hace cuando algo se rompe

Podés simularlo: a mitad del ejercicio, decí que la solución propuesta falló en producción. Se hace cargo y busca la causa, o mira para otro lado? Para mí este punto es clave.

Una rúbrica simple

Para cada señal podés anotar tres niveles: no aparece, aparece con ayuda, aparece sola. No es ciencia exacta, pero ordena la conversación del panel y evita que la decisión dependa solo de los logos del perfil.

Si tu empresa ya contrata con cierta frecuencia, conviene que ese registro no viva en planillas sueltas. Nuestro software de reclutamiento y selección lleva cada candidato del CV al legajo dentro de la misma plataforma.

Dónde entran las certificaciones

Siguen siendo una gran base. Si alguien de tu equipo quiere arrancar, en EGA Futura ofrecemos clases de Salesforce en vivo y gratis. La certificación más el caso práctico te dan una foto mucho más completa que cualquiera de los dos por separado.

El paralelo con los sistemas

Lo mismo que vale para las personas vale para la tecnología: una herramienta no reemplaza un proceso. Por eso, cuando implementamos nuestro ERP nativo para Salesforce, empezamos por entender cómo trabaja la empresa. Y en Vantegrate, cuando diseñamos agentes de IA para empresas, el criterio del equipo pesa más que el modelo.

Cierre

Evaluá habilidades. Poné un caso real adelante. Mirá cómo piensa.

Desarrollé la idea completa, con preguntas frecuentes, en EGA Futura Discover.