> ## Documentation Index
> Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Automatización de workflows
> Transforme sus procesos manuales de revisión documental en workflows automatizados de Omni.
Si su equipo dedica tiempo a revisar documentos manualmente -- comprobando campos, validando datos, haciendo screening de nombres -- Omni puede automatizar gran parte de ese trabajo. Esta guía le ayuda a pensar cómo convertir sus Procedimientos Operativos Estándar (SOPs) existentes en workflows de Omni.
## Identificar oportunidades de automatización
No todos los procesos son aptos para la automatización. Busque estas señales de que su proceso manual de revisión está listo para Omni:
| Señal | Por qué importa |
| ------------------------------ | --------------------------------------------------------------------------------------------- |
| **Verificaciones repetitivas** | Los mismos pasos de verificación se aplican a cada documento |
| **Criterios consistentes** | Las decisiones de aprobación/rechazo siguen reglas definidas, no juicios subjetivos |
| **Alto volumen** | Su equipo procesa decenas o cientos de documentos por día/semana |
| **Riesgo de error humano** | El cansancio o la inconsistencia generan problemas no detectados |
| **Inputs estructurados** | Los documentos siguen un formato predecible (facturas, certificados de registro, formularios) |
### Procesos habituales que Omni puede automatizar
* **Verificación de facturas** — Comprobar montos, fechas, detalles del proveedor, totales de partidas
* **Onboarding de proveedores** — Validar documentos de registro empresarial y hacer screening contra listas AML
* **Revisión de formularios de compliance** — Verificar que los campos requeridos estén presentes y sean válidos
* **Validación de registros empresariales** — Extraer y cruzar datos de la empresa
* **Revisión de contratos** — Verificar términos clave, fechas e información de las partes
* **Verificación de documentos de empleados** — Validar certificaciones, licencias o documentos de identidad presentados
Omni funciona mejor con procesos que tienen **reglas claras y documentables**. Si su proceso de revisión depende mucho de juicio subjetivo o conocimiento institucional que no puede documentarse, puede que convenga automatizarlo de forma parcial en lugar de total.
## Mapear su SOP a un workflow de Omni
Siga estos cinco pasos para convertir un proceso manual en un workflow de Omni.
Antes de construir nada en Omni, anote exactamente cómo su equipo maneja actualmente la revisión:
* **Quién** realiza la revisión?
* **Qué documentos** reciben?
* **Qué revisan** en cada documento?
* **Qué decisiones** toman (aprobar, rechazar, escalar)?
* **Adónde van los resultados** después de la revisión?
Esto se convierte en su línea base. Traducirá cada punto a la configuración de Omni.
Liste cada tipo de documento que se envía para revisión. Sea específico:
* Es un PDF de factura? Un certificado de registro empresarial escaneado? Una hoja de cálculo?
* Hay múltiples documentos por caso, o solo uno?
* Los documentos necesitan cruzarse entre sí?
Omni admite JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML y MD. Hasta **5 items por folder**. Si un caso involucra más de 5 documentos, agrupe documentos relacionados en múltiples folders dentro del mismo profile.
Para cada verificación que realiza su equipo, anote los criterios exactos:
* Qué hace que un documento sea **aceptable**? (p. ej., "Todos los campos requeridos están presentes y el total coincide con las partidas")
* Qué hace que un documento sea **rechazado**? (p. ej., "La fecha de la factura está en el futuro" o "El registro empresarial está vencido")
* Qué desencadena la **escalación** a un revisor senior? (p. ej., "El screening AML devuelve una coincidencia" o "Campos clave son ilegibles")
Estos criterios se convierten en la lógica de decisión de su policy de Omni.
Combine las verificaciones y criterios de los pasos anteriores en una declaración de policy estructurada. Use pasos numerados y lenguaje explícito.
**Plantilla:**
```text theme={null}
Review the submitted [document type] by performing the following checks:
1. Extract [list of fields] from the document
2. Verify that [specific condition]
3. Check that [another condition]
4. [Additional verification steps]
Decision criteria:
- APPROVE if all checks pass and all required fields are present
- REJECT if [specific failure conditions]
- FLAG for manual review if [ambiguous conditions]
```
Consulte la [Guía de redacción de policies](/es/omni/guides/policy-writing-guide) para ejemplos detallados y buenas prácticas.
Decida qué datos estructurados necesitan sus sistemas downstream de cada revisión. Esto se convierte en su output schema.
Pregúntese:
* Qué campos espera su sistema backend?
* Necesita los valores extraídos en bruto, o solo el resultado pass/fail?
* La salida debe incluir las razones de la decisión?
Diseñe el JSON output schema para que coincida exactamente con estos requisitos.
## Ejemplos del mundo real
Estos ejemplos muestran cómo los procesos de revisión manual se traducen en workflows de Omni.
### Ejemplo 1: Revisión de facturas
Un miembro del equipo de finanzas abre cada PDF de factura y verifica manualmente:
* Que el nombre del proveedor y el número de factura estén presentes
* Que la fecha de factura sea razonable (no en el futuro, no mayor a 90 días)
* Que los montos de las partidas sumen el total indicado
* Que los cálculos de impuestos sean correctos
* Que no haya números de factura duplicados en el sistema
**Tiempo por factura:** 5-10 minutos. **Tasa de error:** \~3% (errores de cálculo no detectados, duplicados pasados por alto).
**Policy:**
```text theme={null}
Verify the submitted invoice document by:
1. Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount
2. Verifying all required fields are present and non-empty
3. Validating that the invoice date is not in the future and not older than 90 days
4. Checking that the sum of line item amounts equals the stated subtotal
5. Verifying that tax is calculated correctly based on the subtotal
6. Approve if all checks pass; reject if amounts do not match or required fields are missing; flag for manual review if date is borderline
```
**Engines:** Text Verifier - Glove (extraer y validar todos los campos)
**Output schema:**
```json theme={null}
{
"invoice": {
"vendorName": "string",
"invoiceNumber": "string",
"invoiceDate": "string",
"lineItems": ["string"],
"subtotal": "number",
"tax": "number",
"totalAmount": "number"
},
"validation": {
"allFieldsPresent": "boolean",
"dateValid": "boolean",
"amountsMatch": "boolean",
"taxCorrect": "boolean"
},
"decision": {
"result": "APPROVE | REJECT | MANUAL_REVIEW",
"verificationStatus": "pending_review | approved | rejected",
"reasons": ["string"]
}
}
```
**Resultado:** El tiempo de revisión baja de 5-10 minutos a segundos para facturas sencillas. El equipo solo maneja los casos marcados manualmente.
### Ejemplo 2: Onboarding de proveedores
Cuando se incorpora un nuevo proveedor, un oficial de compliance:
* Revisa el certificado de registro empresarial buscando nombre de la empresa, número de registro y fecha de constitución
* Verifica el documento de identidad del representante
* Busca manualmente el nombre del representante en bases de datos AML/sanciones
* Cruza los datos de la empresa entre documentos
* Registra los resultados en una hoja de cálculo
**Tiempo por proveedor:** 20-30 minutos. **Cuello de botella:** la búsqueda AML es lenta y la consulta manual es propensa a errores.
**Policy:**
```text theme={null}
Verify vendor onboarding documents by:
1. Extracting company name, registration number, incorporation date, and representative name from the business registration certificate
2. Screening the representative's name against AML/sanctions watchlists
3. Cross-validating the representative name between the business registration and any submitted identity documents
4. Checking that the business registration is not expired
5. Approve if no AML matches found, all fields are consistent, and registration is valid; reject if AML screening returns a high-risk match; flag for manual review if AML returns a partial match or fields are inconsistent
```
**Engines:** Text Verifier - Glove + AML Search - Person
**Output schema:**
```json theme={null}
{
"company": {
"name": "string",
"registrationNumber": "string",
"incorporationDate": "string",
"representativeName": "string"
},
"amlScreening": {
"screened": "boolean",
"matchFound": "boolean",
"riskLevel": "string",
"matchDetails": "string"
},
"validation": {
"fieldsConsistent": "boolean",
"registrationValid": "boolean"
},
"decision": {
"result": "APPROVE | REJECT | MANUAL_REVIEW",
"verificationStatus": "pending_review | approved | rejected",
"reasons": ["string"]
}
}
```
**Resultado:** El screening AML es automático e instantáneo. Los casos limpios se aprueban automáticamente. El oficial de compliance se enfoca solo en los proveedores marcados.
### Ejemplo 3: Verificación de documentos de compliance
Un equipo de compliance revisa documentos regulatorios presentados:
* Verifica que todas las secciones requeridas estén presentes (encabezado, firma, fechas, números de licencia)
* Comprueba que las fechas de vencimiento estén en el futuro
* Confirma que el documento está dirigido a la entidad correcta
* Valida que los números de referencia coincidan con los registros internos
**Tiempo por documento:** 10-15 minutos. **Riesgo:** documentos vencidos ocasionalmente se filtran durante períodos de alto volumen.
**Policy:**
```text theme={null}
Review the submitted compliance document by:
1. Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name
2. Verifying that all required sections are present: header, body, signature block, and dates
3. Checking that the expiration date is in the future
4. Validating that the entity name matches the expected entity
5. Approve if all sections are present, the document is not expired, and entity names match; reject if the document is expired or missing required sections; flag for manual review if the entity name is a partial match
```
**Engines:** Text Verifier - Glove (validar completitud y corrección de campos)
**Output schema:**
```json theme={null}
{
"document": {
"type": "string",
"issuingAuthority": "string",
"issueDate": "string",
"expirationDate": "string",
"licenseNumber": "string",
"entityName": "string"
},
"validation": {
"allSectionsPresent": "boolean",
"notExpired": "boolean",
"entityNameMatch": "boolean"
},
"decision": {
"result": "APPROVE | REJECT | MANUAL_REVIEW",
"verificationStatus": "pending_review | approved | rejected",
"reasons": ["string"]
}
}
```
**Resultado:** Los documentos vencidos se detectan automáticamente. Los revisores solo manejan casos límite donde los nombres coinciden parcialmente o las secciones son ambiguas.
## Diseñar output schemas efectivos
Su output schema determina qué datos estructurados obtiene de cada análisis. Diséñelo pensando en sus sistemas downstream.
Todo output schema debería incluir estos tres bloques:
| Bloque | Propósito | Campos de ejemplo |
| ---------------------------- | -------------------------------------------- | ------------------------------------------------- |
| **Datos extraídos** | Valores en bruto obtenidos de los documentos | `vendorName`, `invoiceNumber`, `registrationDate` |
| **Resultados de validación** | Pass/fail por verificación con razones | `amountsMatch`, `dateValid`, `fieldsConsistent` |
| **Decisión** | Veredicto final y estado de routing | `result`, `verificationStatus`, `reasons` |
Si omite el bloque de decisión, tendrá que escribir su propia lógica de decisión basada en los resultados de validación en bruto. Incluir un bloque de decisión permite que el agente de IA tome la decisión final basándose en los criterios de su policy.
## Routing con `verificationStatus`
Cada análisis expone **`verificationStatus`**: `approved`, `pending_review` o `rejected`. Ramifique sus integraciones basándose en ese enum.
| verificationStatus | Acción recomendada |
| ------------------ | ------------------------------------------------------------------ |
| `approved` | Aceptar automáticamente y registrar en sus sistemas |
| `pending_review` | Enviar a una cola humana con los hallazgos de IA y datos extraídos |
| `rejected` | Denegar o cerrar el caso según su policy |
Este enfoque significa que Omni no reemplaza completamente a su equipo de revisión. Aprueba automáticamente los casos directos y envía los ambiguos o fallidos a la cola correcta con contexto.
Monitoree la frecuencia con que aparece cada estado y compare con los resultados manuales. Ajuste el lenguaje de la policy o su output schema cuando las tasas de `pending_review` o `rejected` se desvíen de las expectativas.
### Patrón de implementación
```text theme={null}
if verificationStatus == "approved":
→ auto-accept, record in system
elif verificationStatus == "pending_review":
→ send to reviewer queue with AI findings highlighted
else: # rejected
→ denial flow or manual escalation per policy
```
Integre esta lógica en su backend después de recuperar los resultados del análisis de la Omni API.
## Medir el éxito
Después de desplegar un workflow de Omni, monitoree estas métricas para medir el impacto:
| Métrica | Cómo medir | Objetivo |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **Reducción del tiempo de revisión** | Tiempo promedio por caso antes vs. después | Reducción del 50-80% para casos auto-aprobados |
| **Tasa de error** | Porcentaje de decisiones incorrectas (compare resultados de Omni con verificaciones manuales puntuales) | Igual o menor que la tasa de error manual |
| **Throughput** | Casos procesados por día/semana | Aumento significativo por el procesamiento automático |
| **Tasa de escalación** | Porcentaje de casos enviados a revisión humana | Debería disminuir con el tiempo a medida que refina las policies |
### Enfoque de despliegue recomendado
Elija su proceso de revisión de mayor volumen y más basado en reglas. Cree un workflow de Omni para él y ejecútelo en paralelo con su proceso manual durante 1-2 semanas.
Verifique las decisiones de Omni contra las decisiones manuales de su equipo. Busque discrepancias e investigue si Omni o el revisor humano tenía razón.
Basándose en la comparación, ajuste el lenguaje de su policy, output schema o umbrales de puntuación. Pequeños cambios suelen producir mejoras significativas.
Una vez validada la precisión, deje que Omni maneje el proceso de punta a punta. Luego pase a automatizar procesos de revisión adicionales.
## Siguientes pasos
Guía paso a paso para construir su primer workflow en el dashboard.
Buenas prácticas para redactar policies de verificación efectivas.