Esta guía muestra cómo construir un procedimiento Fin reutilizable que consulta un catálogo de productos a través de tu API, coincide con el artículo solicitado por el cliente, verifica el stock y dirige el flujo según la disponibilidad. Puedes usar este procedimiento para crear nuevos pedidos o actualizar los existentes usando tus APIs de pedidos backend.
Mantén tus propios endpoints de API y nombres de parámetros: reemplaza las URLs de ejemplo, cuerpos de solicitud y nombres de campos con los que expone tu backend. Si no has creado un procedimiento antes, lee primero Building Fin Procedures.
Nota:
Conectores de datos: Necesitas tres conectores específicos:
Uno para devolver un catálogo de productos (GET).
Uno para crear un artículo de pedido (POST).
Uno para actualizar un pedido existente (PUT).
Forma canónica de respuesta: Tus APIs deben devolver una estructura de datos consistente.
Manejo de errores: Para un procedimiento robusto, tus pasos de Condición deben usar los atributos de respuesta
status_codeyerrordevueltos por los Conectores de datos. Esto permite que Fin ramifique según códigos HTTP específicos (p. ej., 400, 500) en lugar de depender de una ruta genérica de éxito/fallo.
Consejo: Conéctate con Expertos de la Comunidad y Arquitectos de Soluciones de Intercom en nuestras Horas de Oficina de Procedures Meetup. Estas sesiones, que se realizan cada dos semanas, ofrecen soporte práctico en tiempo real, incluyendo preguntas y respuestas en vivo para ayudarte a configurar y optimizar tus Procedimientos Fin y conectores de datos.
Configuración de conectores de datos
Crea tres conectores con nombres claros (por ejemplo, Get Product Catalog, Create Order Item, Update Order Item) para ayudar a Fin a identificar la acción correcta.
Recopila cualquier entrada que el conector necesite. Los Atributos Temporales ahora pueden pasarse directamente como entradas a un Conector de datos; si los datos ya existen en una variable temporal, Fin los asigna automáticamente sin pedir al cliente. Configura una entrada como recopilada del cliente solo si el valor no está almacenado. Reemplaza https://api.example.com y los nombres de campos con tus propios endpoints y claves JSON. Para preguntas comunes sobre configuración de conectores, autenticación y ejecución, consulta Preguntas frecuentes sobre Fin y conectores de datos.
1. Get Product Catalog (GET)
Propósito: Devuelve una lista de productos incluyendo id, nombre, precio y stock.
Método: GET.
URL: https://api.example.com/items (o tu endpoint de catálogo)
Encabezados: Content-Type: application/json (+ autenticación según sea necesario)
Respuesta: Un arreglo de objetos de producto.
Example response:
[
{ "id": "sku-100", "name": "Classic T-Shirt", "price": 19.99, "stock": 120 },
{ "id": "sku-101", "name": "Running Shoes", "price": 89.50, "stock": 45 },
{ "id": "sku-104", "name": "Nintendo Switch", "price": 119.00, "stock": 0 }
]
2. Create Order Item (POST)
Propósito: Crea un nuevo pedido o un artículo específico de pedido.
Método: POST.
URL: https://api.example.com/orders (o tu endpoint de creación de pedidos)
Encabezados: Content-Type: application/json (+ autenticación)
Cuerpo de la solicitud: Debe incluir product_id y quantity.
{
"product_id": "<product id>",
"quantity": <integer>
}
Configura las entradas del conector si quieres que Fin recopile product_id y quantity.
3. Update Order Item (PUT)
Propósito: Añade artículos o actualiza un pedido existente.
Método: PUT.
URL: https://api.example.com/orders/{{order_id}} (o PUT /orders/{order_id}/items)
Encabezados: Content-Type: application/json (+ autenticación)
Cuerpo de la solicitud: Debe incluir product_id y quantity.
{
"product_id": "<product id>",
"quantity": <integer>
}Entradas requeridas: order_id, product_id, quantity
Conexión API mostrando variable de ruta order_id y cuerpo de solicitud.
Recopilar entradas de datos listando order_id, product_id, quantity.
Construyendo el flujo del procedimiento
Usa variables temporales para almacenar datos intermedios durante la conversación. Las variables recomendadas incluyen Temporary.SelectedProductID, Temporary.StockLevel y Temporary.OrderAction.
Paso 1: Consulta y búsqueda de producto
Pregunta al cliente: Pregunta, "¿Qué producto te gustaría?".
Llama al Conector de datos: Usa Get Product Catalog.
Lógica: Busca en la lista devuelta un producto cuyo nombre (o SKU) coincida mejor con Temporary.SelectedProductName.
Al coincidir, establece:
Temporary.SelectedProductID = id del producto
Temporary.SelectedProductName = nombre canónico del producto del catálogo
Temporary.StockLevel = stock del producto (convertido a entero)
Validación: Si no se encuentra coincidencia, pide al cliente que aclare o sugiere los productos similares principales del catálogo y vuelve al Paso 1 si elige otro producto.
Notas de implementación
La lógica de coincidencia puede ser una simple búsqueda de subcadena o una coincidencia difusa más sofisticada. Mantén la coincidencia determinista para que los pasos de condición de Fin funcionen de manera fiable.
Paso 2: Verificación de stock y ramificación
Use un bloque lógico estándar IF/ELSE en la interfaz del procedimiento para verificar Temporary.StockLevel. Esta es una comparación de valores sencilla; no necesita una condición de código aquí. Use el generador visual de condiciones y seleccione Temporary.StockLevel como atributo.
IF Temporary.StockLevel > 0: Continúe al Paso 3.
ELSE: Diríjase a la sección "Agotado" (Paso 8).
Paso 3: Preguntar si es un pedido nuevo o existente
Mensaje: “¿Desea crear un pedido nuevo para este artículo o agregarlo a un pedido existente?”
Respuestas aceptadas:
Nuevo → Temporary.OrderAction = "new" → Paso 4
Existente → Temporary.OrderAction = "existing" → Paso 4
Si no está claro, haga una pregunta aclaratoria y repita.
Paso 4 — Preguntar cantidad y validar (actualización menor)
Mensaje: “¿Cuántas unidades desea?” → analizar entero → almacenar en Temporary.Quantity.
Validación:
Si Temporary.Quantity ≤ 0 → preguntar de nuevo.
Si Temporary.Quantity > Temporary.StockLevel → informar al cliente del stock disponible y hacer una de las siguientes:
Ofrecer la cantidad máxima disponible y pedir confirmar una cantidad menor (bucle dentro del Paso 4), o
Ofrecer opciones de pedido pendiente/notificación (Paso 8).
Después de validar la cantidad, continúe al Paso 5 (Decisión de acción del pedido).
Bloques de acción para solicitud y validación de cantidad.
Paso 5: Decisión de acción del pedido (IF / ELSE IF)
En lugar de manejar la creación y actualización de pedidos en línea, dirija cada camino a un subprocedimiento dedicado. Esto mantiene el flujo principal limpio y hace que cada camino sea independiente y testeable. Añada un bloque condicional IF / ELSE IF, luego use @Run sub-procedure en cada rama: Para comparaciones complejas o basadas en fechas, vea Cómo escribir condiciones de código para Fin Procedures.
IF Temporary.OrderAction == 'new': use @Run sub-procedure para invocar el subprocedimiento Create New Order.
ELSE IF Temporary.OrderAction == 'existing': use @Run sub-procedure para invocar el subprocedimiento Update Existing Order.
ELSE (alternativa): escalar al equipo
Paso 6: CREAR NUEVO PEDIDO (subprocedimiento)
Mueva este paso a un subprocedimiento dedicado (por ejemplo, "Create New Order") para mantener el flujo principal legible. Dentro de ese subprocedimiento, llame al conector Create Order Item. Los atributos temporales como Temporary.SelectedProductID y Temporary.Quantity pueden mapearse directamente a las entradas del conector — no se necesita solicitud manual:
product_id = Temporary.SelectedProductID
quantity = Temporary.Quantity
Capture la respuesta en Temporary.NewOrderID (si se devuelve) y almacene el status_code del conector en Temporary.CreateOrderStatus.
En caso de éxito: responder:
“Pedido nuevo creado con [Temporary.Quantity] × [Temporary.SelectedProductName]. ID de pedido: [Temporary.NewOrderID]. ¿Algo más en lo que pueda ayudar?”Ofrezca opciones post-acción (agregar más artículos, cambiar cantidad, pagar, finalizar). Mantenga Temporary.NewOrderID si continúa la sesión.
Agregue un paso de Condición inmediatamente después de la llamada al conector y ramifique según Temporary.CreateOrderStatus. El status_code y los atributos de error pueden aparecer al final del selector de atributos — desplácese hacia abajo si no los ve. Use las siguientes ramas: IF status_code == 200 o 201: continúe a la confirmación de éxito. ELSE IF status_code == 400: informe al cliente que su solicitud fue inválida (por ejemplo, ID de producto o cantidad incorrecta), pídale corregir la entrada y ofrezca reintento. ELSE IF status_code ≥ 500: disculpe por un error del servidor, capture el atributo de error en una nota interna para depuración y escale al Equipo de Soporte E-Comm. ELSE (estado inesperado): registre Temporary.CreateOrderStatus y escale al Equipo de Soporte E-Comm. Para una guía más profunda sobre depuración de fallos de conectores e interpretación de códigos de estado, vea Solución de problemas de Fin Procedures y conectores de datos.
Llamada al conector con entradas mapeadas y mapeo de respuesta (order_id → Temporary.NewOrderID).
Mensaje de confirmación post-acción y opciones.
Paso 7: ACTUALIZAR PEDIDO EXISTENTE (subprocedimiento)
Mensaje: “Por favor, proporcione el ID del pedido existente al que desea agregar este artículo.” → guardar en Temporary.ExistingOrderID.
Llamada: conector Update Order Item con:
order_id = Temporary.ExistingOrderID
product_id = Temporary.SelectedProductID
quantity = Temporary.Quantity
Capture el status_code del conector en Temporary.UpdateOrderStatus y el campo de error (si está presente) en Temporary.UpdateOrderError.
En caso de éxito: responder:
“Se añadieron [Temporary.Quantity] × [Temporary.SelectedProductName] al pedido [Temporary.ExistingOrderID]. ¿Algo más?”
Ofrezca opciones post-acción (agregar más artículos, cambiar cantidad, pagar, finalizar).Agregue un paso de Condición inmediatamente después de la llamada al conector y ramifique según Temporary.UpdateOrderStatus. Como en el Paso 6, el status_code y los atributos de error pueden aparecer al final del selector de atributos. Use las siguientes ramas: IF status_code == 200: continúe a la confirmación de éxito. ELSE IF status_code == 400: informe al cliente que el ID del pedido puede ser inválido, pídale verificar y volver a ingresarlo, y ofrezca reintento. ELSE IF status_code ≥ 500: disculpe por un error del servidor, muestre Temporary.UpdateOrderError en una nota interna y escale al Equipo de Soporte E-Comm. ELSE (estado inesperado): registre el estado y escale al Equipo de Soporte E-Comm. Vea Solución de problemas de Fin Procedures y conectores de datos para una guía completa sobre diagnóstico de fallos de conectores en conversaciones en vivo.
Consejo: Los atributos status_code y error devueltos por un Data Connector pueden aparecer al final del selector de atributos. Desplácese hacia abajo si no los ve inmediatamente — son esenciales para construir ramas robustas de manejo de errores.
Recopilación de ExistingOrderID y la llamada al conector Update que lo usa.
Mensaje de confirmación post-acción y opciones.
Paso 8: AGOTADO
Se activa cuando Temporary.StockLevel ≤ 0 o cuando la cantidad solicitada > disponible y el cliente rechaza la cantidad reducida.
Acciones:
Disculparse y presentar opciones claras:
Mostrar productos similares (mejores coincidencias del catálogo).
Ofrecer pedido pendiente/notificar cuando esté disponible — registrar preferencia de contacto.
Ofrecer cantidad parcial si está disponible.
Si el cliente elige notificar/pedido pendiente → registrar preferencia y confirmar.
Si el cliente elige una alternativa → volver al Paso 1 (Consulta y búsqueda de producto) con la nueva selección.
Finalizar o repetir según la respuesta del cliente.
Próximos pasos
Una vez que su flujo principal de pedidos funcione, considere estos patrones avanzados para manejar resultados más complejos.
Transferir a un Workflow después de crear el pedido
Después de un nuevo pedido exitoso, transfiera a un Workflow (por ejemplo, "Enviar Confirmación de Pedido") para manejar automatizaciones posteriores como recibos por correo electrónico o actualizaciones de CRM. Use un paso Handoff to workflow al final de su subprocedimiento Crear Nuevo Pedido. El procedimiento termina en la transferencia y no se reanudará después de que el Workflow termine, así que haga que este sea el último paso.
Cambiar procedimientos según el resultado del pedido
Si el pedido resulta en un estado específico — por ejemplo, un pedido pendiente o un pago fallido — cambie a un procedimiento dedicado (por ejemplo, "Gestión de Pedidos Pendientes" o "Recuperación de Fallos de Pago") en lugar de manejar todos los resultados en un solo procedimiento. Esto mantiene los procedimientos individuales enfocados y más fáciles de mantener.
Escalar con contexto en fallos repetidos de API
Si el mismo conector falla al reintentar (por ejemplo, dos errores 500 consecutivos), escale a un equipo humano e incluya una nota interna que resuma Temporary.CreateOrderStatus o Temporary.UpdateOrderError para que el compañero tenga todo el contexto sin necesidad de volver a preguntar al cliente.
Encadenar subprocedimientos para carritos con múltiples artículos
Para apoyar a los clientes que ordenan múltiples productos en una sesión, vuelva al subprocedimiento Consulta de Producto después de una acción de pedido exitosa e incremente un contador de artículos. Termine el ciclo cuando el cliente confirme que ha terminado.