Ir al contenido principal

Actualización de tu conexión Salesforce para usar la External Client App y soportar BYOC

Guía paso a paso para actualizar tu conexión Salesforce con Fin para usar la External Client App y pasar de Enhanced Chat a BYOC.

Bring Your Own Channel (BYOC) es una nueva forma para que los clientes de Fin habiliten Fin Messenger como su agente de IA para chat en vivo. Conectarse vía BYOC en lugar de Enhanced Chat mejora cómo el messenger maneja ciertos comportamientos de users, como conversaciones concurrentes en múltiples pestañas, para que puedas seguir disfrutando del servicio de primera clase de Fin. La migración es sencilla, usando entornos de prueba antes de implementarlo en producción sin causar tiempo de inactividad. Sigue la guía a continuación para implementarlo en tu espacio de trabajo.

Usa este artículo para actualizar tu conexión existente de Fin para Salesforce y usar la nueva External Client App (ECA). Esta guía es para admins de Salesforce que migran una implementación existente de Fin para Salesforce: necesitarás acceso de admin de Salesforce y una suscripción activa de Fin para Salesforce. Al final, habrás instalado los paquetes gestionados requeridos, conectado vía la nueva ECA, configurado permisos y — si usas Fin Messenger — establecido una conexión de chat en vivo entre Fin y Salesforce vía Bring Your Own Channel (BYOC), el marco estándar de integración de canales de Salesforce para conectar proveedores de mensajería de terceros.

Hay 6 pasos involucrados:

  1. Conéctate a Salesforce vía la External Client App

  2. Configura permisos

  3. Cambia a usar credenciales de External Client App

  4. Ejecuta el script de migración Apex

  5. Desinstala el paquete obsoleto y desconecta la Connected App

  6. Actualiza tu implementación de Fin Messenger [opcional]

Nota: Si configuras Fin solo para manejar casos de Salesforce (sin mensajería), puedes omitir la sección Actualizaciones a Fin Messenger a continuación.


Paso 1: Conéctate a Salesforce vía la External Client App

Ve a Connect en tu espacio de trabajo Fin, luego haz clic en la pestaña Bring Your Own Channel.

Esta pestaña sirve para la migración hacia la nueva External Client App (ECA), un método de autenticación basado en credenciales de cliente OAuth 2.0 que reemplaza la antigua Connected App (una integración OAuth más antigua que requería almacenar credenciales de users).

Verás tus conexiones existentes listadas como Not Connected en esta pestaña. El estado de la conexión es respecto a la External Client App.

Sigue los pasos a continuación para instalar un paquete gestionado en Salesforce. El paquete gestionado instala la External Client App, además de todos los permisos y campos que Fin necesita para funcionar.

  1. Haz clic en el botón Connect en cualquier conexión existente que quieras conectar (de prueba o en vivo), luego haz clic en Install Package.

  2. Selecciona Install for all users. Esto significa que el conjunto de permisos puede asignarse a cualquier user en tu organización Salesforce si así lo decides.

  3. Espera a que termine la instalación. No deberían aparecer errores.

  4. Una vez completada la instalación, regresa a la página Connect y haz clic en el botón Connect to Salesforce en el Paso 2, luego permite que se establezca la conexión.


Paso 2: Configura permisos

Ve a Connect > External Client App (Tab) > Assign permissions in Salesforce desde tu espacio de trabajo Fin y sigue los pasos allí para crear un nuevo conjunto de permisos y asignar todos los permisos que Fin necesita para funcionar.

Crea un nuevo conjunto de permisos

  1. En Salesforce, crea un nuevo conjunto de permisos. La etiqueta y el nombre API pueden ser cualquiera; este conjunto de permisos solo se asignará al user de integración.

  2. Al seleccionar una licencia, asegúrate de elegir una que incluya el permiso Set Audit Fields upon Record Creation, por ejemplo, la licencia Salesforce. Algunas licencias no incluyen este permiso.

  3. Guarda el nuevo conjunto de permisos.

La pantalla Nueva Conjunto de Permisos en Salesforce, mostrando el desplegable de Licencia configurado en 'Salesforce', el tipo de licencia que incluye el permiso requerido 'Set Audit Fields upon Record Creation'.

Nota: No todos los tipos de licencia de Salesforce incluyen el permiso Set Audit Fields upon Record Creation. Si esta opción no está disponible para una licencia que estás considerando, selecciona otro tipo de licencia (como la licencia estándar de Salesforce) que sí lo incluya.

Asigna conjuntos de permisos al user de integración

Tanto el conjunto de permisos existente Fin for Salesforce permissions como el conjunto de permisos recién creado deben asignarse al user de integración.

  1. En Salesforce, navega al perfil del user de integración.

  2. Ve a Permission Set Assignments y haz clic en Edit Assignments.

  3. Agrega tanto el conjunto de permisos Fin for Salesforce permissions como el conjunto de permisos recién creado a la columna Enabled Permission Sets, luego haz clic en Save.

La pantalla Permission Set Assignments en Salesforce para el user de integración, mostrando tanto 'Fin for Salesforce permissions' como el conjunto de permisos recién creado movidos a la columna Enabled Permission Sets.


Paso 3: Cambia a usar credenciales de External Client App

Puedes cambiar a usar las credenciales de External Client App para una conexión Salesforce activando la opción Use External Client App credentials al gestionar una conexión bajo Connect > External Client App (Tab).

Una vez activado, Fin usa las credenciales de External Client App para todas sus solicitudes a Salesforce, incluyendo:

  • Consultas para obtener el estado de la conexión.

  • Crear un caso de Salesforce vía el paso del workflow.

  • Crear un caso de Salesforce al resolverse Fin o por inactividad del user.

  • Responder a casos creados vía el canal de casos de Salesforce.

  • Importar artículos de Knowledge.

  • Importar casos históricos de Salesforce.

Una vez activado, puedes desactivarlo si crees que algo anda mal. Esto te permite probar en cada entorno — sandbox, UAT (pruebas de aceptación de users) y producción — y ganar confianza con las nuevas credenciales ECA, sin interrumpir las credenciales heredadas de Connected App.

Una vez que todas las conexiones tengan activada la opción Use External Client App credentials, la migración estará completa. El estado de conexión para cada entrada se actualizará a Connected en la pestaña External Client App. Sigue los pasos a continuación para migrar tus datos y limpiar el paquete obsoleto una vez que estés seguro de que todos los sistemas funcionan como se espera.


Paso 4: Ejecuta el script de migración Apex

Cuando instalas el paquete base gestionado Fin for Salesforce, instala nuevos campos Fin Case que están con namespace finai. El namespace significa que cada nombre de campo tiene el prefijo finai__ (por ejemplo, finai__FinConversationId__c) para evitar conflictos de nombres con otros paquetes o campos personalizados en tu organización.

Como parte de la migración, usa el script de migración Apex para mover tus datos de casos existentes de los campos antiguos sin namespace a los nuevos campos con namespace. El paquete Fin for Salesforce incluye una clase Apex preconstruida llamada FinCaseFieldMigrator.cls que maneja la lógica de migración.

El Apex dentro de un paquete gestionado resuelve nombres de campos personalizados no calificados contra su propio namespace. Una consulta para FinConversationId__c ejecutada dentro del paquete finai devuelve finai__FinConversationId__c en su lugar, por lo que el código empaquetado no puede leer los campos heredados, y nombrar ambos en una consulta falla con un error de duplicate field selected. Por eso la migración debe ejecutarse desde fuera del paquete — por eso necesitas agregar las clases abajo manualmente en tu organización. Las clases mismas no contienen lógica de migración; llaman a la clase de migración instalada por el paquete gestionado y la ejecutan en lotes de 200 registros a la vez.

Agregarás dos clases Apex a tu organización, ejecutarás la migración una vez y luego eliminarás ambas clases cuando ya no sean necesarias:

  • FinCaseFieldMigration ejecuta la migración.

  • FinCaseFieldMigrationTest es su prueba. Salesforce no desplegará Apex a producción sin una prueba, y esta también verifica que tu organización esté configurada correctamente antes de que algo se ejecute.

4a. Copia las dos clases

FinCaseFieldMigration

public without sharing class FinCaseFieldMigration implements Database.Batchable<SObject>, Database.Stateful {

private final finai.FinCaseFieldMigrator migrator;

public FinCaseFieldMigration() {
this.migrator = new finai.FinCaseFieldMigrator();
}

public static Id run() {
return run(200);
}

public static Id run(Integer scopeSize) {
if (scopeSize == null || scopeSize < 1 || scopeSize > 2000) {
throw new IllegalArgumentException('scopeSize must be between 1 and 2000, got: ' + scopeSize);
}
return Database.executeBatch(new FinCaseFieldMigration(), scopeSize);
}

public Database.QueryLocator start(Database.BatchableContext bc) {
return Database.getQueryLocator(migrator.queryString());
}

public void execute(Database.BatchableContext bc, List<SObject> scope) {
migrator.migrate(scope);
}

public void finish(Database.BatchableContext bc) {
migrator.report(bc.getJobId());
}
}

FinCaseFieldMigrationTest

@IsTest
private class FinCaseFieldMigrationTest {

private static final String LEGACY_FIELD = 'FinConversationId__c';
private static final String TARGET_FIELD = 'finai__FinConversationId__c';

// Absent legacy field means the old unlocked package was never installed here, so there is
// genuinely nothing to migrate and the test below has nothing to prove. Every other
// precondition is a misconfiguration and is asserted, so it fails the deploy rather than
// passing green on a migration that would silently copy nothing.
private static Boolean orgHasLegacyField() {
return Schema.SObjectType.Case.fields.getMap().containsKey(LEGACY_FIELD);
}

@IsTest
static void copiesLegacyDataOntoTheNamespacedField() {
if (!orgHasLegacyField()) {
return;
}
Map<String, Schema.SObjectField> fields = Schema.SObjectType.Case.fields.getMap();
System.assert(
fields.containsKey(TARGET_FIELD),
TARGET_FIELD + ' does not exist — install the finai managed package before this class'
);
System.assert(
fields.get(LEGACY_FIELD).getDescribe().isAccessible(),
'cannot read ' + LEGACY_FIELD + ' — the legacy permission set must stay assigned'
);
System.assert(
fields.get(TARGET_FIELD).getDescribe().isUpdateable(),
'cannot write ' + TARGET_FIELD + ' — assign finai__Fin_for_Salesforce_permissions'
);

Case seeded = new Case(Subject = 'fin case field migration test', Status = 'New');
seeded.put(LEGACY_FIELD, 'conv-under-test');
insert seeded;
Id seededId = seeded.Id;

Test.startTest();
FinCaseFieldMigration.run();
Test.stopTest();

SObject migrated = Database.query(
'SELECT Id, ' + TARGET_FIELD + ' FROM Case WHERE Id = :seededId LIMIT 1'
)[0];
System.assertEquals(
'conv-under-test',
migrated.get(TARGET_FIELD),
'the legacy value should have been copied onto the namespaced field'
);
}

@IsTest
static void runReturnsAJobId() {
Test.startTest();
Id jobId = FinCaseFieldMigration.run(50);
Test.stopTest();
System.assertNotEquals(null, jobId, 'run() should return the id of the batch job it queued');
}

@IsTest
static void runRejectsAScopeSizeOutsideTheBatchLimits() {
for (Integer scopeSize : new List<Integer>{ null, 0, 2001 }) {
try {
FinCaseFieldMigration.run(scopeSize);
System.assert(false, 'expected IllegalArgumentException for scopeSize ' + scopeSize);
} catch (IllegalArgumentException e) {
System.assert(
e.getMessage().contains('scopeSize must be between 1 and 2000'),
'unexpected message: ' + e.getMessage()
);
}
}
}
}

4b. Agrega las clases a tu organización Salesforce

Cómo hacerlo depende de la organización que estés migrando.

Migrando un sandbox

  1. Ve a Setup > Apex Classes y haz clic en New.

  2. Pega el código de FinCaseFieldMigration y haz clic en Save.

  3. Haz clic en New nuevamente, pega el código de FinCaseFieldMigrationTest y haz clic en Save.

  4. Haz clic en Run All Tests, o abre FinCaseFieldMigrationTest y haz clic en Run Test, y confirma que pase.

Migrando producción con un change set (no se necesita línea de comandos)

Las organizaciones de producción no permiten crear clases Apex en Setup, así que créalas en un sandbox y despliega desde ahí.

  1. En un sandbox conectado a producción, con el nuevo paquete instalado, crea ambas clases como se describió arriba.

  2. En el sandbox, ve a Setup > Outbound Change Sets y haz clic en New. Agrega ambas clases Apex y haz clic en Upload, eligiendo tu organización de producción como destino.

  3. En producción, ve a Setup > Deployment Settings y asegúrate de que tu sandbox tenga permiso para enviar cambios entrantes.

  4. En producción, ve a Setup > Inbound Change Sets, abre el change set y haz clic en Deploy.

  5. En Choose a Test Option, selecciona Ejecutar pruebas especificadas, ingresa FinCaseFieldMigrationTest y haz clic en Deploy.

Migrando producción con la Salesforce CLI

Guarda cada clase como un archivo .cls en una carpeta case-field-migration/classes/. Junto a cada uno, agrega un archivo .cls-meta.xml con el mismo nombre (por ejemplo, FinCaseFieldMigration.cls-meta.xml) que contenga:
​

<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>62.0</apiVersion>
<status>Active</status>
</ApexClass>

Luego ejecuta:

sf project deploy start \
--source-dir case-field-migration \
--target-org <your-org-alias> \
--test-level RunSpecifiedTests \
--tests FinCaseFieldMigrationTest

Qué te indica un despliegue exitoso: durante el despliegue, la prueba crea un Caso temporal, lo migra y verifica que el valor haya llegado al nuevo campo. Salesforce revierte los datos de prueba después. Así que un despliegue exitoso significa que la migración ya funciona en tu organización. Si el despliegue falla, el mensaje de error indica la razón, por ejemplo, un paquete faltante o un conjunto de permisos faltante.

4c. Ejecuta la migración

  1. Ve a Salesforce setup > Developer Console

  2. Haz clic en Debug > Open Execute Anonymous Window

  3. Pega el código abajo, haz clic en Execute

    Id jobId = FinCaseFieldMigration.run();
    System.debug('Fin Case field migration job: ' + jobId);


    La migración procesa 200 Casos por lote por defecto. Si tu organización tiene triggers, flujos u otra automatización en Case que alcance límites de gobernador a ese tamaño, usa un tamaño de lote menor:

    FinCaseFieldMigration.run(50);

4d. Verifica el resultado

  • Setup > Apex Jobs muestra el progreso del trabajo FinCaseFieldMigration.

  • Cuando el trabajo termina, el administrador que lo inició recibe un correo con el informe. Enumera cada Caso que fue omitido o falló, con el campo y la razón.

Lee el informe en lugar de asumir que la ejecución funcionó. Si faltaba un conjunto de permisos cuando lo ejecutaste, el trabajo puede terminar "exitosamente" sin haber copiado nada. El informe te dirá qué campos omitió.

Puedes ejecutar la migración de nuevo con seguridad. Solo llena campos nuevos que aún estén vacíos, así que una segunda ejecución no actualiza ningún registro.

Lo que la migración no hace:

  • No elimina ni cambia nada en los campos antiguos.

  • No puede revertirse.

  • Las dos casillas, Fin Involved y Fin Marked As Spam, solo se copian cuando el valor antiguo está marcado. Una casilla sin marcar no se puede distinguir de una que nunca se estableció, por lo que no se copia. De cualquier forma, el nuevo campo queda sin marcar.

4e. Elimina las clases

Una vez que el informe muestre una ejecución limpia, elimina tanto FinCaseFieldMigration como FinCaseFieldMigrationTest. No omitas esto: mientras estas clases estén en tu organización, Salesforce no te permitirá desinstalar el paquete Fin for Salesforce.

  • Sandbox: ve a Setup > Apex Classes y haz clic en Del junto a cada clase.

  • Producción: Apex no puede eliminarse desde Setup en producción, así que usa la Salesforce CLI.

    • En una carpeta vacía, crea destructiveChanges.xml:

      <?xml version="1.0" encoding="UTF-8"?>
      <Package xmlns="http://soap.sforce.com/2006/04/metadata">
      <types>
      <members>FinCaseFieldMigration</members>
      <members>FinCaseFieldMigrationTest</members>
      <name>ApexClass</name>
      </types>
      </Package>

    • Luego crea un archivo package.xml en la misma carpeta:

      <?xml version="1.0" encoding="UTF-8"?>
      <Package xmlns="http://soap.sforce.com/2006/04/metadata">
      <version>62.0</version>
      </Package>

    • Desde esa carpeta, ejecuta:

      sf project deploy start \
      --manifest package.xml \
      --post-destructive-changes destructiveChanges.xml \
      --target-org <your-org-alias> \
      --test-level RunLocalTests

      Esto ejecuta las pruebas existentes de tu organización, como cualquier despliegue en producción. Si falla en una prueba que no sea FinCaseFieldMigrationTest, el problema está en esa prueba, no en la migración. Arréglalo como lo harías con cualquier otro despliegue.


Paso 5: Desinstala el paquete obsoleto y desconecta la Connected App

Una vez instalado el nuevo paquete gestionado, todas las conexiones se cambian a las credenciales ECA, y los datos del campo Fin Case se han migrado a los nuevos campos con espacio de nombres, desinstala el paquete desbloqueado o no gestionado anterior y revoca la conexión de la Connected App heredada.

Desasignar PermissionSet heredado

El PermissionSet heredado (un objeto de Salesforce que otorga a los users acceso a funciones y campos específicos) debe desasignarse antes de que se pueda desinstalar el paquete.

  1. Ve a Configuración de Salesforce > Paquetes instalados

  2. Haz clic en el paquete desbloqueado Fin for Salesforce

  3. Haz clic en Ver componentes

  4. Haz clic en el Fin_for_Salesforce_permissions PermissionSet, esto te llevará a la página de PermissionSet.

  5. Haz clic en Administrar asignaciones

  6. Selecciona todos los Salesforce Users asignados

  7. Haz clic en el botón Quitar asignación

Desinstalar paquete y guardar datos

  1. Ve a Configuración de Salesforce > Paquetes instalados

  2. Haz clic en Desinstalar junto al paquete desbloqueado Fin for Salesforce

    La página de Paquetes instalados de Salesforce con el paquete desbloqueado Fin for Salesforce listado y un botón 'Desinstalar' visible a su derecha.
  3. Selecciona Guardar una copia de los datos de este paquete durante 48 horas después de la desinstalación, esto guardará todos los datos de campos de casos como un csv con una columna para el ID de caso de Salesforce.

    Importante: Salesforce conserva la exportación de datos guardados solo por 48 horas después de la desinstalación. Descarga el CSV antes de que cierre esa ventana. Si ya ejecutaste el script de migración Apex con éxito, no necesitarás restaurar desde este archivo, pero es una red de seguridad útil.

  4. Espera a recibir la notificación de que la desinstalación del paquete se completó con éxito.

  5. Vuelve a Configuración de Salesforce > Paquetes instalados, deberías ver el paquete desinstalado listado bajo Paquetes desinstalados.

  6. Haz clic en Datos, esto descargará todos los datos de casos como un csv almacenado dentro de un archivo zip. Guarda este archivo zip de forma segura ya que podrías usarlo para restaurar datos si es necesario. Pero si ya ejecutaste el script de migración Apex, deberías estar listo.

    La lista de Paquetes desinstalados de Salesforce mostrando el paquete Fin for Salesforce con un enlace de descarga 'Datos', usado para descargar la exportación CSV guardada de datos de campos de casos dentro de la ventana de 48 horas.

Revocar conexión de la aplicación conectada

  1. Ve a Configuración de Salesforce > Uso de OAuth de aplicaciones conectadas

  2. Haz clic en el enlace numérico listado debajo de la columna Conteo de usuarios para la aplicación conectada Fin for Salesforce. Te redirigirá a Uso de usuarios de la aplicación conectada.

    La página de Uso de OAuth de aplicaciones conectadas de Salesforce mostrando la aplicación conectada Fin for Salesforce con un enlace numérico de conteo de usuarios en la columna Conteo de usuarios, que abre la pantalla de Uso de usuarios de la aplicación conectada.
  3. Haz clic en Revocar junto a cada usuario listado. Esto elimina los tokens de acceso OAuth almacenados como parte de la conexión heredada de la aplicación conectada. Una vez revocados, esos usuarios ya no aparecen en la lista.

    La pantalla de Uso de usuarios de la aplicación conectada de Salesforce mostrando entradas individuales de usuarios con un enlace de acción 'Revocar' junto a cada uno, usado para eliminar los tokens de acceso OAuth heredados.


Paso 6: Actualiza tu despliegue de Fin Messenger

Sigue estos pasos solo si planeas usar Fin for Salesforce con Mensajería.

Esta sección explica cómo conectar Fin como un socio Bring Your Own Channel (BYOC) en Salesforce, y cómo migrar los workflows existentes de entrega de Enhanced Chat para usar BYOC en su lugar.

Conectar Fin a Bring Your Own Channel

Para establecer la conexión BYOC entre Fin y Salesforce, sigue el Paso 1 del artículo Fin Messenger: Configuración con Salesforce. Ese paso te guía para crear un canal de mensajería, configurar el Event Relay y activar el canal en Salesforce.

Una vez completado, deberías tener un canal de mensajería activo con un Event Relay en funcionamiento — una función de Salesforce que transmite eventos de plataforma en tiempo real, usada aquí para pasar mensajes entre Fin y Salesforce — entre Fin y Salesforce.

Entrega a agente de Salesforce

El paso Entrega a agente de Salesforce en los workflows de Fin Messenger ahora soporta alternar entre BYOC y Enhanced Chat. Esto te permite controlar qué canal usa la entrega mientras pruebas, para que puedas cambiar gradualmente sin tiempo de inactividad.

El editor de workflows de Fin Messenger mostrando el paso 'Entrega a agente de Salesforce', con un interruptor para cambiar entre los modos de entrega BYOC y Enhanced Chat.

Puedes crear múltiples workflows con diferentes audiencias y segmentación de entorno para controlar qué tráfico pasa por BYOC
​


O podrías aprovechar el paso Branches en workflows con la variable Environment para dirigirlo a un paso de Entrega a agente de Salesforce con BYOC activado vs uno con BYOC desactivado (es decir, Enhanced Chat)
​


Preguntas frecuentes

¿Cuánto tiempo toma la migración?

Los pasos técnicos suelen tomar 1–2 horas. Sin embargo, si realizas el ciclo completo de pruebas — primero sandbox, luego UAT (pruebas de aceptación de usuarios), luego producción — permite 1–2 días hábiles en total. La variable principal es cuántos entornos de Salesforce validas antes de poner en vivo.

¿Hay algún tiempo de inactividad?

No se espera tiempo de inactividad. El interruptor Usar credenciales de aplicación cliente externa puede desactivarse en cualquier momento si algo parece incorrecto, y tanto Enhanced Chat como BYOC pueden funcionar simultáneamente durante la transición.

¿Se requieren licencias o complementos adicionales de Salesforce?

Para que BYOC funcione necesitas la licencia Digital Engagement SKU con el complemento Partner Messaging. Una forma de verificar si tienes la licencia relevante es,

  1. Ve a Configuración de Salesforce > Información de la empresa

  2. Verifica si tienes Partner Messaging User listado bajo Licencias de conjuntos de permisos y el total de licencias disponibles.

Contacta a tu Ejecutivo de Cuenta de Salesforce (AE) si te falta la licencia o el complemento para que los habiliten en tu organización de Salesforce.

¿Existe algún riesgo de sobrescribir datos existentes de Salesforce?

  • Existe un riesgo de pérdida de datos (específicamente los campos personalizados de casos de Fin) al desinstalar el paquete desbloqueado/no gestionado anterior.

  • Sin embargo, eso se mitiga ejecutando el script de migración Apex y/o descargando los datos de casos como parte de la desinstalación.

  • No hay riesgo asociado con sobrescribir datos existentes de Salesforce con esta migración específicamente.

¿Ha quedado contestada tu pregunta?