Adding a delay to AOP
How it works end to end
- The AOP reaches the delay step and invokes the delay tool, passing along any inputs it needs (for example, the target date).
- Because the tool is configured with Wait for callback = ON, the AOP execution pauses at this step.
- Inside the workflow, the Delay Node holds the request — for a fixed period, or until a date/time resolved at runtime from the inputs.
- When the delay elapses, the workflow's End node fires its custom callback back to the AI Colleague.
- The callback resumes the AOP, which continues with its next step.
Workflow callbacks fire only when the workflow is executed via an AI Colleague. This pattern depends on the AOP being the initiator of the workflow.
Step 1 — Build the delay workflow
Create a new workflow (e.g., Delay with callback). The canvas looks like this:
The Trigger Sync block between the Manual Trigger and Initiator Input can be left empty (default).
1.1 Input form
Attach a form to the Initiator Input node with the fields the delay needs. For a dynamic (date-based) delay, that is typically a Date field plus any context you want to carry through:
| Field | Type |
|---|---|
| target_date | Date · Full date · format DD-MMM-YYYY |
| (any context fields, e.g., userId, name) | Text |
Mark the fields as required. When the AOP invokes this skill, the agent fills these fields conversationally from the data it has received — no manual input is needed.
1.2 Function node: date format conversion (optional)
The Delay Node uses strict date parsing — the incoming date string must exactly match the configured format. If your source format differs (for example, the date picker outputs DD-MMM-YYYY with
dashes, but you configure the Delay Node with dd/mmm/yyyy), add a Function node to bridge the two.
| Setting | Value |
|---|---|
| Create function | Create via GPT — prompt: "Convert date from dd-mmm-yyyy format to dd/mmm/yyyy format" |
| Argument | {{forms.<Form name>.target_date}} |
The generated function looks like this:
function execute(dateStr) {
const { DateTime } = luxon;
const dt = DateTime.fromFormat(dateStr, 'dd-LLL-yyyy');
if (!dt.isValid) {
throw new Error('Invalid date format');
}
return dt.toFormat('dd/LLL/yyyy');
}Use Test with a sample date (expected output: {"data":"28/Jan/1994","status":200}), then save it to the Data Center so the key is available to the Delay Node downstream.
1.3 Delay node
See the Delay Node reference for full configuration details. For this pattern, the key decisions are:
- Delay type: Use Dynamic when the wait differs per request (e.g., "wait until this user's last working day"), resolving the target date from the Data Center key produced above (e.g.,
{{nodes.Convert date.executionData.data}}). Use Fixed when the wait is the same for every request (e.g., "always wait 5 minutes for propagation"). - Fixed offset: A date-only format resolves to midnight of that day. Enable Use Fixed Offset with Add Time (e.g., +10 hours to fire around 10:00 AM) so the release time is deliberate. Use
Subtract Time to act before the target date — for example, sending a reminder two days early. - Fallback type: If the resolved date is invalid, choose Complete Immediately when the steps after the delay must still run — an action like access revocation should never be silently dropped
because of a bad date. The default, Skip, stops the workflow from progressing to the next node, which would leave the AOP waiting.
If the resolved date is already in the past, the Delay Node completes immediately and the workflow proceeds without waiting.
1.4 End node: enable the callback
| Setting | Value |
|---|---|
| Enable custom callback | ON |
| Custom callback body | { "status": "completed" } |
This callback is what wakes the paused AOP. Without it, the AOP would wait forever after invoking the skill. Publish the workflow when
done.
Step 2 — Register the workflow as a skill
On the AI Colleague, add the published workflow as a Custom skill (category: Workflows) with:
| Setting | Value |
|---|---|
| Wait for callback | ON — the AOP must pause until the workflow's End-node callback arrives |
| Description | A clear statement of purpose, e.g., "This tool is designed to add a delay in AOP execution" — the agent uses the description for tool selection |
Skills invoked after the delay (the actual action) are registered the same way but normally with Wait for callback = OFF, unless the AOP also needs to wait on their result.
Step 3 — Use the delay skill in your AOP
In the AOP instruction, invoke the delay tool at the step where execution should pause, and place the follow-up action in the next step. Tag each tool with @ so it renders as a linked tool:
Step N: Add Delay Until Target Date
Invoke the delay tool with the target date (and any context fields). This will pause the AOP execution until the specified date is reached.
Tools to use: @Delay with callbackStep N+1: Perform the Action
Once the delay has completed and a callback is received, trigger the follow-up action.
Tools to use: @<your action>
Publish the AOP to create its active version.
Worked example: delayed user deactivation
A common application of this pattern is an off-boarding helper AOP that deactivates a user on their date of relieving:
- A primary AOP (or manual execution) hands the helper three fields:
name,userId, anddate_of_relieving. The helper validates all three are present and prompts for anything missing. - The helper invokes @Delay with callback, passing the three fields. The AOP pauses.
- Inside the workflow, the relieving date is reformatted, and the Delay Node holds the request until that date +10 hours (~10:00 AM on the relieving day).
- When the delay elapses, the End node's callback resumes the AOP.
- The AOP invokes the revoke-access skill to mark the user inactive.
The fallback on the Delay Node is set to Complete Immediately — if a malformed date ever reaches the workflow, access revocation still runs right away rather than being silently dropped.
The helper's instruction, for reference:
Step 1: Receive User Information
Receive the record details passed from the primary AOP including the employee name, user ID, and date of relieving. Validate that all three fields are present before proceeding. If any of the required
fields are missing, prompt for the missing information before continuing.Step 2: Add Delay Until Date of Relieving
Invoke the delay tool with the provided user ID, name, and date of relieving. This will pause the workflow execution until the specified relieving date is reached.
Tools to use: @Delay with callbackStep 3: Trigger Inactive/Revoke Access
Once the delay has completed and a callback is received and the date of relieving has been reached, trigger the revoke access tool for the user to mark them as inactive.
Tools to use: @Revoke user access
Testing your delay
- Run the AOP manually (enable manual execution on the AOP for testing) with a near-term target date. Remember that a date already in the past completes immediately.
- Confirm the AOP pauses after invoking the delay skill — the request should sit in a waiting state, not complete.
- Confirm the workflow request shows the Delay Node as in-progress until the target time.
- Feed a malformed date to verify the fallback: with Complete Immediately, the follow-up action should still fire right away.
- After the callback, verify the AOP resumed and invoked the follow-up skill.
Related pages
- Delay Node — full configuration reference
- Referencing AOPs, Tools in AOP Instructions
- Understanding AOP type
- How to create a new Workflow
Updated about 13 hours ago
