Conectar apps de campo con Salesforce sin romper tu org

Salesforce es donde la mayoría de los equipos comerciales quiere tener su pipeline. Pero las personas que generan buena parte de ese pipeline, como canvassers, vendedores en campo, instaladores y aliados, suelen trabajar en condiciones donde la experiencia estándar de Salesforce no es la herramienta adecuada. Necesitan un flujo móvil rápido, tolerancia a la falta de conexión y una pantalla diseñada para lo único que hacen todo el día.

La respuesta suele ser una app a la medida que alimenta Salesforce. Bien hecha, le da al campo una herramienta que de verdad usa y le da al liderazgo comercial datos limpios y a tiempo. Mal hecha, llena la org de duplicados, consume los límites de API y crea una integración que nadie quiere tocar.

Este artículo cubre los patrones que usamos al construir apps de campo conectadas a Salesforce, con base en nuestra experiencia en Salesforce y más de 20 años de entrega, incluida una app de generación de leads para canvassers en el sector de remodelación residencial.

Empieza por el modelo de datos de Salesforce, no por las pantallas

Los errores más costosos en estos proyectos vienen de diseñar primero la app y mapearla a Salesforce después. Para entonces, la app tiene su propia idea de lo que es un lead y la integración se vuelve una capa de traducción llena de excepciones.

Empieza en la org:

• ¿Qué objeto crea un registro de campo? ¿Lead, Contact, un objeto personalizado o directamente una Opportunity? La respuesta depende de cómo tu proceso comercial califica y convierte, no de lo que le resulte cómodo a la app.
• ¿Qué hace único a un registro? Dirección, teléfono, correo o una combinación. Define las reglas de coincidencia antes de escribir el primer registro y hazlas cumplir en Salesforce, no solo en la app.
• ¿Quién es dueño del registro? Las reglas de asignación, los territorios y las colas deben funcionar igual para los registros creados desde la app que para los que se ingresan en Salesforce.
• ¿Qué campos se necesitan para el siguiente paso del proceso? Si ventas no puede actuar sobre un registro de campo sin volver a llamar al canvasser, la app está recogiendo los datos equivocados.

Con estas decisiones claras, los formularios de la app casi se diseñan solos.

Elige la API correcta para cada flujo

No toda interacción entre la app y Salesforce debe usar el mismo mecanismo. Algunas reglas prácticas:

• Escrituras de un registro en tiempo real (un canvasser envía un lead): encajan en la REST API, idealmente a través de un servicio del lado del servidor y no directamente desde el dispositivo.
• Operaciones por lotes (sincronizaciones nocturnas, importaciones, cargas históricas): encajan en Bulk API 2.0. La guía de Salesforce indica que las operaciones con más de 2.000 registros son buenas candidatas para ella, mientras que los trabajos más pequeños deben usar llamadas síncronas agrupadas (documentación para desarrolladores de Salesforce).
• Cambios a los que la app debe reaccionar (una oportunidad cambia de etapa, un lead se reasigna): es mejor recibirlos por eventos que consultarlos periódicamente. Consultar cambios a cada rato es una de las formas más rápidas de consumir capacidad de API sin aportar valor.

Un servicio de integración liviano entre la app y Salesforce te da un solo lugar para manejar autenticación, reintentos, límites de uso y registros. También te permite cambiar la app o la org sin romper la otra.

Da visibilidad a los usuarios externos, con cuidado

Una de las funciones más valiosas para los equipos de campo es ver qué pasa después de enviar un lead. ¿Se convirtió en cita? ¿Se cerró? En la app de canvassing que construimos, los usuarios externos podían seguir el estado y la evolución de sus leads a medida que avanzaban en las oportunidades de Salesforce. Esa visibilidad cambia el comportamiento: el equipo de campo ve cuáles de sus leads se convierten y mejora la calidad de lo que envía.

Pero el acceso externo es donde el gobierno de la org más importa:

• El licenciamiento para usuarios externos se decide temprano. El tipo de acceso que elijas determina a qué objetos y registros pueden llegar los usuarios externos, y cambiarlo tarde es costoso.
• El modelo de compartición debe ser explícito. Los usuarios externos deben ver sus propios registros y nada más. Pruébalo con perfiles de usuario reales, no con una cuenta de administrador.
• Expón solo lo que ayuda. Un estado y una fecha suelen ser suficientes. Las notas internas, los precios y los datos de otros vendedores se quedan adentro.

Protege la org de la app

Una app de campo puede generar muchos registros rápidamente. Sin controles, también puede disparar todas las automatizaciones de la org en cada escritura. Antes de salir a producción, revisa:

• La automatización en los objetos destino. Flows, triggers y reglas de validación escritas para ingreso manual pueden comportarse distinto con volumen. Nuestro artículo sobre arquitectura Apex para plataformas Salesforce empresariales explica por qué aquí importa un framework de triggers gobernado.
• La gestión de duplicados. Las reglas de coincidencia y de duplicados deben ejecutarse sobre los registros creados por la app, con una decisión clara sobre si bloquear, fusionar o marcar.
• El manejo de errores. Cuando Salesforce rechaza un registro, el usuario de campo debe recibir un mensaje claro y el registro debe quedar en cola para reintento o revisión, en lugar de perderse.

Prueba con el campo, no solo en un sandbox

Los sandboxes son esenciales, pero no reproducen a un canvasser parado en un porche con mala señal y un propietario esperando. Planea un piloto con un grupo pequeño de usuarios reales antes del despliegue completo:

• Mide cuánto tarda un envío de principio a fin.
• Registra cuántos envíos necesitan corrección en Salesforce después.
• Pregunta a los usuarios qué se saltan o qué resuelven por fuera de la app.

El piloto casi siempre revela uno o dos campos que sobran y uno que falta. Corregirlos antes del despliegue sale mucho más barato que volver a capacitar a todo un equipo de campo.

El equipo que necesitas

Estos proyectos están en el cruce entre desarrollo móvil, ingeniería de integración y conocimiento de la plataforma Salesforce. En nuestro trabajo con Salesforce, la composición del equipo depende del cliente: algunos proyectos necesitan más profundidad senior en Salesforce desde el primer día; otros combinan desarrolladores mid-level en la app con ingenieros senior y tech leads que intervienen en las decisiones de modelo de datos, la arquitectura de integración y la automatización compleja. Lo importante es que quienes construyen la app entiendan la org, y que quienes son dueños de la org confíen en la app.

Una lista de verificación corta

Antes de conectar una app de campo con Salesforce:

1. ¿El objeto destino y la ruta de conversión están acordados con operaciones comerciales?
2. ¿Las reglas de coincidencia y duplicados están definidas y se aplican en la org?
3. ¿Hay un servicio de integración entre la app y Salesforce?
4. ¿Cada flujo usa la API correcta, con eventos en lugar de consultas periódicas cuando es posible?
5. ¿El acceso externo está acotado y probado con perfiles reales?
6. ¿Se revisó la automatización existente pensando en volumen?
7. ¿Hay un piloto en campo planeado antes del despliegue completo?

En resumen

Una app de campo conectada a Salesforce debe mejorar ambos lados: una herramienta más rápida para quienes generan la demanda y datos más limpios y oportunos para quienes cierran el negocio. Puedes ver cómo funcionó para una empresa de remodelación residencial en nuestros casos de estudio.

Si estás planeando una app a la medida que debe trabajar con tu org de Salesforce, hablemos.