Integraciones
Trabajan sobre los sistemas que tu empresa ya utiliza
No hace falta migrar nada ni modernizar el ERP antes de empezar. Ofyra normaliza la información de tus sistemas —venga de una base de datos, de una API o de un archivo que alguien deja en una carpeta— para que los Officers trabajen sobre hechos consistentes.
¿Cómo se conecta Ofyra a los sistemas de una empresa?
Un conector de Ofyra declara de dónde viene un dato, con qué frecuencia se sincroniza, con qué credencial de solo lectura, cómo se interpreta su formato y a qué hecho canónico corresponde cada campo. Los Officers nunca consumen el sistema de origen: consumen hechos ya normalizados, así que el mismo Officer funciona igual sobre una base de datos que sobre un archivo delimitado. Cuando un proceso necesita registrar algo en un sistema de la empresa, la acción se ejecuta llamando a una API que la propia empresa expone y autoriza endpoint por endpoint.
Integraciones
Trabajan sobre los sistemas que tu empresa ya utiliza.
Ofyra normaliza la información de tus sistemas para que los Officers trabajen sobre hechos consistentes, independientemente del origen. Cada conector se configura por cliente: qué lee, con qué frecuencia y con qué credenciales.
Sistemas de negocio
- ERPLectura de solo lectura por base de datos, API o archivo generado.
- CRMLectura, y registro de oportunidades por API autorizada.
- Sistemas de RR.HH.Padrón, saldos, contratos, incidencias.
- Control de asistenciaMarcaciones por archivo o base de datos.
Datos y archivos
- Bases de datosCredenciales de solo lectura, consultas acotadas, sincronización incremental.
- APIs RESTLectura, y escritura sólo en endpoints autorizados uno por uno.
- Excel y CSVDetección de columnas y validación con muestra antes de operar.
- SFTP · OneDrive · correoEl archivo llega donde ya llega hoy; el conector lo recoge.
- Almacenamiento documentalDocumentos y comprobantes del proceso.
Canales de comunicación
- WhatsApp Business APIAtención de clientes y colaboradores.
- Microsoft TeamsNotificaciones y atención interna.
- CorreoEntrada de documentos y salida de resúmenes.
- Portal del colaboradorAcceso web sin tiendas de aplicaciones.
- CalendariosLectura de disponibilidad y coordinación de citas.
Hechos, no orígenes
Un Officer nunca consume el sistema de origen: consume hechos ya normalizados. Un archivo delimitado por SFTP y una consulta a una base de datos producen el mismo hecho, y el Officer se comporta igual. Migrar de origen después es cambiar la configuración del conector, no un proyecto.
Lectura con permisos de solo lectura
La conexión a tus sistemas puede hacerse con credenciales restringidas a lectura. Los conectores están aislados del motor: si uno falla, el Officer sigue operando con el último dato bueno y la plataforma lo marca en lugar de decidir a ciegas.
La escritura va por tu API, endpoint por endpoint
Cuando un proceso necesita registrar algo en tu sistema, la acción se ejecuta llamando a una API que tu organización expone y autoriza explícitamente, con el payload validado contra un esquema y clave de idempotencia. La plataforma no escribe en las bases de datos de sus clientes.
La sincronización también se vigila
Cada conector reporta su estado, su última sincronización y sus errores. Y hay una vigilancia sobre la ausencia: si el archivo de hoy nunca llegó, eso abre un caso en lugar de pasar desapercibido.
Cómo se configura un conector
Cuatro pasos, y ninguno a ciegas.
Configurar un conector no es un proyecto de integración: es declarar el origen, revisar el mapeo y validar con datos reales antes de que un Officer empiece a decidir sobre ellos.
Origen y frecuencia
Se declara de dónde viene el dato —archivo, base de datos, API, calendario— y cada cuánto se sincroniza.
Mapeo de campos
Las columnas del origen se corresponden con el formato canónico. El asistente propone el mapeo y una persona lo confirma.
Validación con muestra
Antes de operar, se corre una muestra real y se revisa el resultado. Nada entra a producción sin verse.
Sincronización incremental
A partir de ahí el conector avanza con un cursor: sólo trae lo nuevo, y reporta su estado y sus errores.
La escritura, en detalle
Cuando un Officer tiene que registrar algo en tu sistema.
Ofyra no escribe en las bases de datos de sus clientes: esa capacidad no existe en la plataforma. La única vía de vuelta es una API que tu organización expone y autoriza, y este es el recorrido completo de una escritura.
La regla decide
Una condición del proceso se cumple sobre hechos ya calculados de forma exacta. La regla es configuración de tu empresa, con versión publicada.
Se compone el payload
La plantilla de payload se llena con los datos del caso y se valida contra el esquema del endpoint antes de salir.
Aprobación, si corresponde
Si la acción compromete a la empresa o afecta a una persona, espera el visto bueno de alguien en la bandeja.
Se llama a tu API
La llamada va al endpoint que tu organización expuso y autorizó, con clave de idempotencia para que un reintento nunca duplique.
Queda auditada
Regla y versión, hechos, payload, respuesta de tu API y quién aprobó: todo en el registro exportable.
La frontera se mantiene incluso en los procesos regulados: Ofyra inyecta el hecho —una incidencia, una amonestación propuesta, un lead calificado— por la puerta de tu API. Lo que tu sistema haga después con ese dato es cálculo suyo, nunca de la plataforma.
Cuéntanos qué sistemas usa tu operación y te decimos qué puede leer un Officer desde el día uno.
Evaluar mi casoPreguntas frecuentes
Sobre integraciones y conectores.
¿Puede Ofyra conectarse a mi ERP?
Sí, mediante lectura de solo lectura: una consulta a la base de datos con credenciales restringidas, una API REST que el ERP exponga, o un archivo que el ERP genere y deposite por SFTP, OneDrive o correo. Si el proceso exige devolver información al ERP, se habilita un endpoint específico de su API, autorizado uno por uno y con cada llamada auditada.
¿Puede Ofyra conectarse a bases de datos?
Sí, con credenciales de solo lectura y consultas acotadas, con sincronización incremental. Los datos se normalizan a un formato canónico antes de que el Officer los use, de modo que el mismo Officer funciona igual sobre una base de datos que sobre un archivo delimitado.
¿Ofyra escribe directamente en mis bases de datos?
No, y no es una configuración que se pueda cambiar: la capacidad de escribir en la base de datos de un cliente no existe en la plataforma. Cuando un proceso necesita registrar algo en un sistema de la empresa, la acción se ejecuta llamando a una API que la propia empresa expone y autoriza endpoint por endpoint, con el payload validado contra un esquema, clave de idempotencia para no duplicar nunca y registro de cada llamada.
Veamos si un Officer puede hacerse cargo de tu proceso.
Una sesión de descubrimiento de 45 minutos: nos cuentas un proceso que hoy consume tiempo de tu equipo y evaluamos juntos qué partes podría asumir un Officer, con qué reglas y qué supervisión. Si ya hay un Officer listo para tu caso, lo ves funcionando en la misma sesión.
45 min · Revisamos un proceso real de tu empresa