> ## 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.
# Crear un workflow
> Guía paso a paso para crear su primer workflow de Omni desde cero.
Esta guía recorre la creación de un workflow en el dashboard de Omni. Un workflow define la lógica de verificación -- la policy, los engines y el formato de salida -- que Omni aplica cada vez que ejecuta un análisis.
## Requisitos previos
Antes de comenzar, asegúrese de tener:
* Una cuenta de ARGOS Omni con acceso al dashboard
* Un proyecto creado en el dashboard ([ver Gestión de proyectos](/es/omni/dashboard/project-management))
* Una API key para ejecutar análisis después de la configuración ([ver Autenticación](/es/omni/getting-started/authentication))
Cada proyecto admite hasta **10 workflows**. Si necesita más, cree un proyecto adicional.
## Pasos de creación del workflow
Crear un workflow involucra cuatro pasos en el dashboard. Cada paso se construye sobre el anterior.
Comience dando a su workflow un **nombre** y una **descripción** opcional.
* **Nombre** — Una etiqueta corta y descriptiva para el workflow (p. ej., "Revisión de facturas", "Verificación KYB de proveedor"). Así identificará el workflow en el dashboard y en las respuestas de la API.
* **Descripción** — Un resumen breve de lo que hace este workflow. Es solo para referencia de su equipo y no afecta cómo Omni procesa los documentos.
Use convenciones de nombres que reflejen el tipo de documento y el propósito de verificación. Por ejemplo: "Factura - Validación de montos" o "KYB - Registro empresarial". Esto facilita gestionar múltiples workflows en un proyecto.
Escriba una **policy en lenguaje natural** que describa qué debe verificar Omni. Este es el núcleo de su workflow: le indica al agente de IA qué revisar, qué extraer y cómo tomar decisiones.
Su policy debe incluir:
* Los tipos de documentos que espera
* Los pasos de verificación específicos (qué revisar)
* Los criterios de aprobación/rechazo (qué constituye una aprobación vs. un rechazo)
**Ejemplo de policy:**
```text theme={null}
Verify the submitted invoice by:
1. Extracting the vendor name, invoice number, date, and total amount
2. Checking that all required fields are present and non-empty
3. Validating that the invoice date is not in the future
4. Cross-checking that line item totals match the stated total amount
5. Approve if all checks pass; reject if any critical field is missing or amounts do not match
```
Las policies vagas producen resultados vagos. Sea específico sobre qué documentos esperar, qué campos verificar y cuáles son sus criterios de aprobación. Consulte la [Guía de redacción de policies](/es/omni/guides/policy-writing-guide) para buenas prácticas detalladas.
Basándose en su policy, Omni sugiere automáticamente qué engines de IA activar. Revise las sugerencias y active o desactive engines según lo necesite.
**Engines disponibles actualmente:**
| Engine | Descripción |
| ------------------------- | ------------------------------------------------------------------------------------------------ |
| **AML Search - Person** | Busca personas en listas globales AML/sanciones (consulta a base de datos externa) |
| **Text Verifier - Glove** | Extrae texto, valida campos y cruza datos entre documentos (basado en RAG, sin consulta externa) |
En la mayoría de los casos, la sugerencia automática es correcta. Si su policy menciona screening de nombres contra listas de vigilancia, se sugerirá AML Search. Si su policy se enfoca en extracción y validación de documentos, se sugerirá Text Verifier. Siempre puede ajustar esto manualmente.
Defina la **estructura JSON** de los resultados que desea recibir. Esto le indica a Omni exactamente qué formato devolver después del análisis: nombres de campos, tipos de datos y estructura.
**Ejemplo de output schema:**
```json theme={null}
{
"invoice": {
"vendorName": "string",
"invoiceNumber": "string",
"date": "string",
"totalAmount": "number",
"lineItems": ["string"]
},
"validation": {
"allFieldsPresent": "boolean",
"amountsMatch": "boolean",
"dateValid": "boolean"
},
"decision": {
"result": "APPROVE | REJECT | MANUAL_REVIEW",
"verificationStatus": "pending_review | approved | rejected",
"reasons": ["string"]
}
}
```
Use la pestaña **Field Builder** para añadir campos visualmente, o **JSON Schema Input** para editar el schema como JSON. La guía de escritura de schema al final del paso resume las reglas de Draft-07 y las restricciones de Omni (ver [Output Schema](/es/omni/dashboard/workflow-setup/output-schema)).
Incluya siempre un **bloque decision** con un campo de resultado, `verificationStatus` y un array de razones. Esto permite el routing automatizado en sus sistemas downstream. Consulte la [documentación de Output Schema](/es/omni/dashboard/workflow-setup/output-schema) para más detalles.
## Alinee la terminología entre policy, nombres de Item y output schema JSON
Cuando use **términos técnicos** u **objetivos de verificación** específicos (como tipos de documento), utilice la **misma redacción** en los tres lugares siguientes.
| Capa | Qué mantener consistente |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Policy** | Nombres de documentos y etiquetas de objetivos en su policy en lenguaje natural |
| **Nombre del Item** | El nombre que da a cada documento al añadirlo a un profile (p. ej., el campo `name` al crear o subir un Item vía la API) |
| **JSON output schema** | Nombres de campos, descripciones y cualquier texto contextual que haga referencia a esos documentos o verificaciones |
Por ejemplo, si la policy dice que revisará un **certificado de registro empresarial**, registre el Item con la **misma etiqueta** (p. ej., el término equivalente que su equipo usa de forma consistente en coreano o inglés), y use ese mismo término en el output schema donde describe la validación de ese documento. Esa alineación ayuda al agente a conectar de forma confiable la policy, los archivos subidos y los resultados estructurados.
En un **JSON output schema** definido por el cliente, mantenga alineadas también las **descripciones y el contexto** de valores específicos. Por ejemplo, si un campo como `document_validation` es `true`, la descripción asociada debe referirse al mismo tipo de documento (p. ej., registro empresarial) y aclarar qué significa "información suficiente" (nombre de la empresa, dirección, representante y otros campos esperados en ese documento).
En **tiempo de ejecución**, cada vez que añada un Item, establezca **`item.name`** (o el campo **name** del Item en la API) para que coincida con la **redacción de la policy** y la **terminología usada en su JSON output schema**. Si estos divergen, el agente puede mapear incorrectamente documentos y campos.
## Después de la creación
Una vez completados los cuatro pasos, su workflow está listo para usarse. Puede abrirlo desde la lista de workflows para gestionar **profiles y análisis**, o revisar **policy, engines y output schema** desde la vista de configuración del workflow.
### Uso del workflow vía la API
Con su workflow creado, siga este flujo para ejecutar verificaciones:
Cada caso de verificación (p. ej., una factura, un proveedor) obtiene su propio profile dentro del workflow.
```bash theme={null}
curl -X POST "http://client-omni-api.argosidentity.com/v1/workflows/{workflowId}/profiles" \
-H "x-api-key: your-api-key-here" \
-H "Content-Type: application/json" \
-d '{"name": "Invoice #1234 - Acme Corp"}'
```
Suba los documentos a verificar en el folder del profile.
```bash theme={null}
curl -X POST "http://client-omni-api.argosidentity.com/v1/folders/{folderId}/items/upload" \
-H "x-api-key: your-api-key-here" \
-F "file=@/path/to/invoice.pdf" \
-F "type=file"
```
Haga polling del estado de los items hasta que todos los documentos cargados alcancen el estado `ACTIVE`. Esto significa que el OCR y la extracción de texto se completaron.
```bash theme={null}
curl -X GET "http://client-omni-api.argosidentity.com/v1/profiles/{profileId}/items/status" \
-H "x-api-key: your-api-key-here"
```
Haga polling cada **1 segundo** con un **timeout de 60 segundos**. No dispare el análisis hasta que todos los items estén en `ACTIVE`.
Ejecute el análisis. Omni aplica automáticamente su policy, engines y output schema.
```bash theme={null}
curl -X POST "http://client-omni-api.argosidentity.com/v1/profiles/{profileId}/analyze" \
-H "x-api-key: your-api-key-here"
```
Obtenga los resultados estructurados que coinciden con su output schema.
```bash theme={null}
curl -X GET "http://client-omni-api.argosidentity.com/v1/profiles/{profileId}" \
-H "x-api-key: your-api-key-here"
```
Para el flujo API completo con ejemplos detallados de solicitud/respuesta, consulte la [Guía de inicio rápido](/es/omni/getting-started/quickstart).
## Consejos para el éxito
Si su caso de uso coincide con una de las [plantillas de workflow](/es/omni/guides/workflow-templates) (KYB, factura, AML, compliance), empiece por allí y personalice. Es más rápido que construir desde cero.
Después de crear un workflow, ejecute algunos profiles de prueba con documentos reales para validar que su policy y schema produzcan los resultados esperados. Ajuste según sea necesario.
Su primer borrador de policy puede no ser perfecto. Revise los resultados del análisis, identifique dónde la IA malinterpretó su intención y refine el lenguaje de la policy. Pequeños cambios en la redacción pueden mejorar significativamente la precisión.
Diseñe su output schema para que coincida con lo que su backend o sistema de compliance espera. Esto elimina la necesidad de transformaciones de postprocesamiento.
## Siguientes pasos
Aprenda buenas prácticas para redactar policies de verificación efectivas.
Convierta sus procesos de revisión manual en workflows automatizados.