Salesforce es una plataforma multiusuario con límites de ejecución estrictos, y eso condiciona por completo cómo se integra la firma electrónica. Lo que en un servidor propio se resuelve con una llamada síncrona y un archivo en memoria, aquí choca contra topes de tiempo, de memoria y de llamadas externas por transacción. Ignorarlos no produce un error elegante: produce una excepción en medio de la operación del usuario.
La consecuencia práctica es que en Salesforce la firma siempre se diseña como un proceso asincrónico con estado propio, y el binario del documento se mueve lo menos posible dentro de la plataforma.
Salesforce no es un gestor documental
Los archivos viven en la plataforma como contenido asociado a registros, con su propio versionado. Sirve perfectamente como punto de acceso y como índice, pero no como repositorio de cientos de miles de documentos firmados con requisitos de retención a diez años. El almacenamiento de archivos es un recurso limitado del contrato y crece más rápido de lo que nadie proyecta.
El diseño recomendable separa tres cosas: el registro del proceso de firma en la plataforma, el binario en un repositorio externo pensado para eso, y el hash del documento firmado guardado en el registro para poder verificar después que el archivo no cambió.
Un objeto propio para la solicitud de firma
La tentación es agregar dos campos a Oportunidad ("firmado" y "fecha de firma") y seguir adelante. Funciona hasta que un contrato necesita dos firmantes, o se rechaza, o se firma dos veces por versiones distintas. Un objeto dedicado a la solicitud de firma resuelve todos esos casos y aporta algo más valioso: un historial consultable.
Campos que casi siempre hacen falta:
- Referencia al registro de origen y a la versión exacta del documento.
- Firmante previsto y su rol (representante legal, apoderado, cliente).
- Estado del ciclo y, por separado, el motivo del último error.
- Identificador externo devuelto por el servicio de firma, para conciliar.
- Hash del archivo firmado y marca de tiempo de la verificación.
Con ese modelo, preguntas como cuántos contratos llevan más de tres días esperando firma se responden con un informe estándar y no con una consulta a soporte.
Límites de plataforma y el patrón asincrónico
Sin entrar en cifras que cambian entre versiones y ediciones, hay tres familias de límites que afectan directamente a esta integración:
| Límite | Efecto en la firma | Cómo se evita |
|---|---|---|
| Tiempo de llamada externa | La operación de firma puede tardar más que el tope permitido | Llamada corta que encola en el servicio externo y respuesta inmediata |
| Memoria por transacción | Cargar el PDF completo codificado agota la memoria disponible | Enlaces temporales de descarga en vez de enviar el binario |
| Llamadas por transacción | Un proceso masivo agota el cupo a mitad del lote | Procesamiento por lotes con trabajos asincrónicos |
| Operaciones tras modificar datos | No se pueden hacer llamadas externas después de escribir en la transacción | Separar la escritura del envío mediante trabajo diferido |
La regla que resume todo: Salesforce dispara y registra; el trabajo pesado ocurre afuera. Esta separación además facilita reutilizar el mismo servicio de firma desde otros sistemas de la empresa, como se plantea en cómo integrar una API de firma electrónica.
Credenciales: nunca en un campo personalizado
Las credenciales del servicio de firma se administran con los mecanismos de credenciales con nombre de la plataforma, que guardan el secreto fuera del alcance del código y permiten rotarlo sin desplegar nada. Lo que no debe hacerse, aunque se vea con frecuencia:
- Guardar la clave en un campo personalizado de un objeto de configuración visible para administradores.
- Dejar el token en un registro de configuración que viaja en los paquetes de despliegue.
- Escribirlo en el código, aunque sea temporalmente "para probar": queda en el control de versiones para siempre.
Y la regla de fondo: la clave privada del certificado no entra a Salesforce en ninguna forma. La plataforma se autentica ante un servicio autorizado a firmar; el material criptográfico permanece en el entorno del proveedor, en un almacén de secretos o en un módulo de hardware, como se explica en administración y control de certificados en la nube.
El retorno: webhooks hacia Salesforce
Cuando la firma termina, alguien tiene que avisar. Consultar en bucle desde un trabajo programado funciona con volumen bajo, pero desperdicia cupo de llamadas y agrega retraso. La alternativa es exponer un punto de entrada público que reciba la notificación del servicio de firma, con tres cuidados innegociables:
- Verificar el origen de cada notificación con el mecanismo de firma de mensajes que provea el servicio; un punto público sin verificación es una puerta abierta para marcar contratos como firmados.
- Ser idempotente: procesar dos veces el mismo evento no debe generar dos adjuntos ni disparar dos correos.
- Responder rápido y procesar después: aceptar el evento, encolarlo y devolver acuse, en vez de hacer todo el trabajo dentro de la petición.
Los tres puntos, con su lógica de reintentos, están desarrollados en webhooks de firma electrónica.
Entornos de prueba y datos clonados
Los entornos de prueba de Salesforce suelen refrescarse con datos de producción, y ahí aparece un riesgo específico de esta integración: que un entorno de pruebas con datos reales apunte al servicio de firma productivo y empiece a enviar correos a clientes reales pidiendo firmas de contratos que no existen. Dos medidas evitan el incidente:
- La dirección del servicio y las credenciales se definen por entorno y se revisan como parte del procedimiento de refresco.
- Existe un modo de simulación que devuelve respuestas con la misma estructura pero sin firmar ni notificar a terceros.
Qué medir
- Tiempo entre creación de la solicitud y firma efectiva, por tipo de documento.
- Porcentaje de solicitudes que terminan en error definitivo y su causa dominante.
- Solicitudes huérfanas: enviadas al servicio sin retorno, que indican notificaciones perdidas.
- Documentos firmados que no pasan una verificación posterior, señal de un problema en la cadena o en el almacenamiento. El método está en validar firmas de forma programática.
Si el proceso incluye contratos comerciales con varias personas firmando en orden, el diseño del circuito conviene revisarlo junto con firma electrónica en flujos de documentos.
Los certificados del proyecto
Firmas.com.ec emite certificados de firma electrónica con trámite 100% en línea y entrega en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI. Para procesos automatizados desde Salesforce, la firma en la nube es la opción operativamente viable. El precio actualizado, por tipo y por cantidad de firmantes, está en la página de precios.
La coordinación que ninguna integración captura
El grupo también desarrolla Omnifox, una plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja compartida.
Mientras un contrato circula, la conversación con el cliente ocurre por WhatsApp, correo o teléfono, y suele quedar fuera del CRM. Omnifox reúne esos canales en una bandeja compartida, con historial por contacto y asignación por responsable, para que el equipo comercial no dependa de capturas de pantalla. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede firmar un PDF directamente desde código en la plataforma?
No es el enfoque adecuado. Las operaciones criptográficas con la clave privada del certificado se ejecutan en un servicio externo o en el entorno del proveedor; la plataforma coordina el proceso y guarda el resultado.
¿Cómo manejo un contrato con varios firmantes?
Con un registro por firmante asociado a la misma solicitud, cada uno con su estado. Así se puede saber quién falta sin recorrer correos y se puede reenviar solo al que no firmó.
¿El almacenamiento de archivos me va a quedar corto?
Es probable si se guardan todos los binarios firmados en la plataforma. Conviene definir desde el inicio una política de archivo externo y dejar en el registro la referencia y el hash.
¿Qué hago si el servicio de firma no responde?
Reintentos con espera creciente y un tope, después del cual la solicitud pasa a una bandeja de revisión. Nunca reintentos indefinidos: agotan el cupo de llamadas y ocultan un problema real.
¿Necesito un paquete gestionado?
Solo si vas a distribuir la integración a varias organizaciones. Para un único entorno corporativo, componentes desplegados con el procedimiento habitual son más simples de mantener.
Si tu equipo está diseñando la integración de firma electrónica sobre Salesforce y necesita definir el esquema de certificados, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.