«Envía el seguimiento dos días después de la oferta», «espera al sistema de pagos antes de leer el estado», «no dispares todo en el mismo segundo» — las preguntas de tiempos aparecen en uno de cada dos escenarios de automatización en Bitrix24 (Alaio). La plataforma tiene varios mecanismos de retardo, cada uno pensado para una escala distinta, y la mayoría de los calendarios rotos vienen de usar el equivocado. Esta guía los ordena: retardos integrados para minutos y días, un robot para segundos y un patrón de fecha calculada para el «ahora no, pero sí en el momento justo».

¿Qué opciones de retardo trae Bitrix24 de serie?

Dos. Una regla de automatización puede configurarse para ejecutarse con retardo — minutos, horas o días después de que el registro entre en la etapa —, lo que cubre el clásico «recordar en 2 días si no hay respuesta» sin herramientas extra. Dentro del diseñador de procesos de negocio, la actividad de pausa retiene el proceso hasta que pasa un intervalo o llega una fecha concreta, y esa fecha puede venir de un campo del registro. Ambos son fiables y gratuitos; su límite es la granularidad — piensan en minutos y días, no en segundos, y retrasan un paso entero, no el hueco entre dos robots dentro de una misma cadena.

¿Cuándo hace falta una pausa de unos segundos?

Cuando dos pasos consecutivos compiten entre sí. El proceso actualiza un registro y el robot siguiente lo lee antes de que la actualización se asiente; un servicio externo confirma la recepción pero necesita un momento antes de que el resultado sea consultable; dos integraciones escriben en la misma ficha y chocan. Pausa corta existe exactamente para esto: espera el número de segundos indicado — un valor medido en segundos, no en horas —, devuelve una señal de éxito y la cadena continúa. Colocada entre «escribir» y «releer», convierte un fallo intermitente e irreproducible en una secuencia aburridamente estable.

¿Cómo retraso una acción hasta una fecha calculada?

La pausa integrada sabe esperar hasta una fecha guardada en un campo — el truco está, pues, en calcular esa fecha. Fecha más cercana según condición elige la fecha más próxima que cumple tu regla y la escribe en el registro, y la actividad de pausa o una regla con retardo se dispara justo entonces. Diferencia entre dos fechas cubre el caso inverso: convertir «cuánto hace desde la última actividad» en un número que una condición puede comparar, para que el proceso decida si esperar siquiera. Los patrones de aritmética de fechas — formatos, zonas horarias, tipos de campo — están reunidos en la guía de fechas.

¿Qué trampas tienen las pausas largas?

Tres, todas aprendidas por las malas. Un proceso en marcha conserva la lógica con la que arrancó: editar la plantilla no cambia las instancias que ya duermen en una pausa, así que una corrección solo se despliega a medida que las instancias viejas terminan — cuenta con ese solapamiento. Las instancias que duermen mucho se acumulan: cientos de procesos en pausa durante un mes retienen cada uno su estado y ensucian la monitorización, así que prefiere el diseño orientado a eventos — termina el proceso y deja que una regla nueva se dispare en el siguiente cambio de etapa — antes que un proceso gigante que duerme a lo largo de todo el embudo. Y no encadenes llamadas de Pausa corta para fabricar esperas de minutos: está construida para huecos de segundos entre pasos, mientras que los retardos de minuto en adelante pertenecen a los mecanismos integrados, que sobreviven a los reinicios por diseño.

Por dónde seguir

Audita tus plantillas actuales en busca de los dos malos olores: carreras de segundos parcheadas con retardos nativos de minutos (sustitúyelos por una pausa corta) y gigantes que duermen meses (trocéalos en reglas por etapa). La guía de procesos de negocio cubre cómo estructurar procesos para que los tiempos queden a la vista, y la colección de ejemplos de automatización incluye ambos patrones de retardo en contexto.