When nobody decides before the time set on the approval node, the request expires and the workflow continues down its expired path. It is never treated as approved: every approval node must have three labelled edges, approved, rejected and expired, so the “no answer” case always goes somewhere you chose.
The rest of this post covers what that means in practice. One thing first: an approval is a step you add to a workflow. Wetel does not pause actions for approval on its own.
flowchart LR P{{approval}} -- approved --> A["carry on"] P -- rejected --> R["decline politely"] P -- expired --> E["tell the customer someone will follow up"]Why are all three paths required?
Because a missing path would mean a silent default. Wetel refuses to save or publish a workflow whose approval node lacks any of the three labels, and refuses any other or unlabelled edge on that node. The expired edge may lead to the same step as rejected if you want both handled the same way.
How long does a request wait?
By default, 72 hours. You set the time per node with expiresAfterSeconds, from 1 second up to a maximum of 14 days; a longer value is refused when the workflow is saved or published. Pick a time that matches how long the person on the other end can reasonably wait.
What should go on the expired path?
Something safe and honest. The usual choice is a reply that tells the person nobody has decided yet, and that a human will follow up. The walkthrough in the docs uses exactly that:
“I haven’t heard back from the team yet. Someone will follow up with you.”
What the expired path should not do is the risky action itself. If the step needed a person’s yes, “no answer” is not a yes.
When the run continues, the decision is saved in a variable you name. For an expiry it records expired as the decision, no decider, and the original payload, unedited. A later step can read it, for example to log the case for a person to pick up.
What does the owner see?
When a request opens, every active workspace owner gets an in-app notification titled “Approval needed”, and the request appears in the approvals inbox with its title, summary and deadline. Only workspace owners can read the inbox or decide.
Once the deadline passes, the request cannot be decided any more, even in the short gap before a background process closes it as expired. A late “approve” is refused rather than acted on.
Can someone withdraw a request instead?
Yes. An owner can cancel a pending request. Note the difference: a cancelled request does not follow any path. The run stays paused and does not resume, so use cancel when the conversation should simply stop there, and let expiry handle “we ran out of time”.
Will anyone be emailed?
Not yet. Notices are in-app only today. The node accepts an email option, but no email is sent, so do not rely on email to reach an approver.
Does the customer hear anything while it waits?
Only if you say so. The approval node itself says nothing to the end user. Put a reply before it (“I’ve asked a manager to review this”) so the person knows a human is checking.
Can I test the expired path without waiting?
Yes. In a draft test you can simulate EXPIRED (or APPROVED, REJECTED): the node completes at once and the workflow follows only that path. No real request is created and nobody is notified.
Related reference docs
- Approval node: fields, the default and maximum expiry, and what the saved decision holds
- Edge labels: approved, rejected and expired: why all three are required
- Draft tests: simulate each outcome without creating a request
To build one end to end, follow Human approval: a walkthrough.