Servicios de integración con Salesforce para empresas

Desarrollamos lo nuevo sobre Lightning Experience con Lightning Web Components (LWC), Apex y Flow Builder. Para clientes que siguen en Classic, hacemos un descubrimiento para equiparar las páginas de Visualforce, los S-Controls, los botones de JavaScript y los flujos de Process Builder con sus equivalentes en LWC y Flow, y después migramos de forma incremental tras un permission set. No escribimos componentes Aura nuevos salvo para ampliar un paquete heredado, y nunca escribimos flujos nuevos de Process Builder: el estándar es Flow Builder con Auto-Layout.

Toda integración se bulkifica por defecto: un SOQL dentro de un bucle es un fallo en la revisión de código, y usamos Database.Stateful con Queueable Apex o Batch Apex para cualquier carga de más de 200 registros. Para la sincronización externa preferimos Platform Events y Change Data Capture frente al sondeo, con Salesforce Connect (OData) para la lectura directa del ERP cuando el total de registros supera los 5 millones y el coste de almacenamiento importa más que la latencia. Monitorizamos con Event Monitoring + Splunk y alertamos sobre el tiempo de CPU de Apex y los límites de filas de SOQL antes de que se superen.

Sí. El patrón depende de los requisitos de volumen y de latencia. Para SAP S/4HANA, Oracle NetSuite y Microsoft Dynamics 365 usamos MuleSoft Anypoint con los conectores de SAP y NetSuite, o Boomi para integraciones más ligeras. Para data warehouses (Snowflake, BigQuery, Redshift) usamos Salesforce Data Cloud o un pipeline de CDC mediante Fivetran/Hightouch. Para marketing integramos Marketing Cloud, Pardot/Account Engagement, Braze y HubSpot mediante API documentadas con claves de idempotencia y dead-letter queues en cada endpoint.

Salesforce DX con desarrollo guiado por el código fuente en GitHub. Paquetes desbloqueados para metadatos modulares, scratch orgs para las ramas de funcionalidades y Copado o Gearset para los pipelines de promoción a Dev → Integration → UAT (Partial Copy) → Staging (sandbox Full) → Production. Exigimos más de un 85 % de cobertura de pruebas de Apex (no el mínimo del 75 %), ejecutamos PMD y Salesforce Code Analyzer en cada PR y usamos SFDX Hardis para las auditorías de deuda técnica. Los lanzamientos se entregan con una cadencia de dos semanas, con feature flags controlados mediante Custom Permissions.

Estamos alineados con el RGPD · preparados para ISO 27001 · SOC 2 Type II en curso, firmamos DPA y el texto de subencargados alineado con Salesforce, y trabajamos dentro de Salesforce Shield cuando es necesario: Platform Encryption con cifrado determinista para los campos filtrados, Event Monitoring para la auditoría y Field Audit Trail para la retención de hasta 10 años. Para clientes de la UE desplegamos en la región Hyperforce EU de Salesforce, con la residencia de datos confirmada en los ajustes de la instancia de la organización antes del arranque.

Las integraciones son de alcance cerrado y todo incluido, presupuestadas en USD y por niveles según la parte de su stack que toque el trabajo. Una integración puntual cuesta desde $700 (1–2 semanas); varios sistemas conectados entre sí, desde $2,100 (2–4 semanas); un bus de integración reutilizable, desde $5,200 (4–8 semanas); un contorno de integración empresarial completo, desde $10,400 (8–12 semanas). Lo que hace variar la cifra es el número de sistemas, el patrón de sincronización (una integración puntual única frente a un bus de eventos reutilizable), el volumen de datos y la latencia, y la superficie de cumplimiento. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de escribir una sola línea de código: sin recargo por intermediación, sin sobrecostes por herramientas, y la nube corre en sus propias cuentas. Cada proyecto incluye un repositorio SFDX, un pipeline de CI, documentación técnica y una garantía de 30 días tras el lanzamiento sobre los endpoints de integración.

Sí, y casi siempre se hace por fases y no de golpe (big-bang). Empezamos con una evaluación de preparación: SFDX Hardis inventaría sus páginas de Visualforce, S-Controls, componentes Aura, botones de JavaScript y flujos de Process Builder, y después puntúa la complejidad de la migración y estima el esfuerzo por componente. El plan de migración se controla mediante permission sets, de modo que los usuarios pasan a Lightning de forma incremental mientras Classic sigue activo para los equipos que aún no están listos. Las páginas de Visualforce se envuelven en Lightning App Builder o se reimplementan como LWC; Process Builder y las Workflow Rules pasan a ser Flows; los botones de JavaScript pasan a ser Quick Actions con Apex o Flow. No damos una migración por terminada hasta que la adopción de Lightning supere el 95 % y la Salesforce Lightning Usage App no muestre picos de sesiones de Classic. El plazo típico es de 8–16 semanas según el número de páginas y automatizaciones personalizadas; la interrupción se limita a los ciclos de pruebas en el sandbox, no al cutover en producción.

Sí. Las arquitecturas multiorganización aparecen sobre todo cuando una empresa adquiere a otro cliente de Salesforce, cuando una matriz gestiona organizaciones de marca separadas o cuando un ISV publica un paquete gestionado en organizaciones suscriptoras. Diseñamos primero el modelo de datos entre organizaciones: qué objetos viven en cada una, qué se sincroniza en ambos sentidos y qué es de solo lectura, y cómo la gestión de identidades (SSO, connected apps, Named Credentials) abarca varias organizaciones. Para la sincronización entre dos organizaciones solemos usar Platform Events con suscripciones entre organizaciones, Heroku Connect como relé de datos o MuleSoft cuando el gobierno ya reside ahí. Para la arquitectura multi-tenant de ISV usamos Apex protegido y aislamiento de namespace, de modo que la personalización del suscriptor no choque con las actualizaciones del paquete. También acotamos la vía de fusión de organizaciones de Salesforce en escenarios de adquisición en los que el estado final es una única organización.

Sí. Revenue Cloud (antes CPQ y Billing) y su integración con los sistemas de reconocimiento es una especialidad propia. Para CPQ configuramos reglas de producto, reglas de precio, venta guiada y cadenas de aprobación alineadas con su proceso de presupuestación; para Billing conectamos las modificaciones de suscripción, los cargos por uso y la facturación con su libro mayor (NetSuite o Sage Intacct). Para el reconocimiento de ingresos según ASC 606 e IFRS 15, usamos la asignación SSP nativa de Revenue Cloud o construimos un objeto de calendario de reconocimiento a medida, según la complejidad de sus contratos. Si Stripe o Chargebee es la fuente de verdad de facturación, sincronizamos los eventos de suscripción en Salesforce mediante pipelines de webhook a Platform Event, asignando las líneas de factura a Opportunity Products para que el ARR de renovación y el MRR de churn lleguen al CRM sin conciliación manual. La integración de CPQ con el ERP suele tener el objeto Order de Salesforce como punto de traspaso, con la sincronización del ERP activada al activar el pedido.

La decisión depende de tres factores: el número de endpoints, si la integración necesita un contrato reutilizable y lo que el cliente ya tiene. REST directo (callouts de Apex, Platform Events, Named Credentials) es la opción correcta para una integración acotada de un solo endpoint en la que usted controla ambos lados, el volumen es inferior a 50k registros/día y no hay ya una licencia de iPaaS; es lo más rápido de construir y lo más barato de operar. MuleSoft Anypoint es la opción correcta cuando la organización conecta cinco o más sistemas y el negocio necesita una capa de contratos de API gobernada con conectores reutilizables (SAP, NetSuite, Workday); solo el conector de SAP de MuleSoft ahorra semanas frente a escribir a mano las llamadas RFC o BAPI. Boomi es un nivel intermedio rentable: menor precio por conexión que MuleSoft y mejor para organizaciones que necesitan integración visual low-code sin la profundidad nativa de Salesforce. Recomendamos Boomi cuando la cartera de integraciones es amplia pero los sistemas implicados tienen API bien documentadas y la organización no necesita la gobernanza ni las métricas de ejecución de MuleSoft. Nunca recomendamos un iPaaS cuando un Platform Event directo o una Named Credential resuelven el problema: pagar un middleware para hacer de proxy en una sincronización entre dos sistemas es una carga de ingeniería sin beneficio.