The short answer
A LinkedIn acceptance branch needs an explicit event, a deadline and a separate next action for each outcome. In this example, an accepted request leads to a DM after one day; no acceptance within seven days leads to email. A production workflow also needs a rule for late acceptance and replies.
Published by Beel. Beel is in development. Its public builder is a planning demo; competitor features are based on linked documentation checked October 16, 2026. Read our editorial approach.
At a glance
Swipe the table to see all columns.
| What to compare | What it means | What to check |
|---|---|---|
| Start | Connection request at day 0. | Check whether the person is already connected. |
| Accepted example | Acceptance at day 0, then a one-day wait. | DM at day 1 in this illustrative scenario. |
| Fallback example | No acceptance during a seven-day window. | Email at day 7 if its additional delay is zero. |
| Late acceptance | Acceptance after the fallback deadline. | Decide whether to keep the email path or change it; avoid duplicate follow-up. |
| Any reply | A reply changes the conversation. | Verify how the live tool stops or changes future outreach. |
Define the event before drawing the branch
“Accepted” needs a precise meaning. Is the person already a connection when the sequence starts, or did they accept the request sent by this sequence? What if a request was already pending? These cases should not be treated as interchangeable without checking the tool’s behavior.
HeyReach documents a connection-status condition, while lemlist describes time-bound acceptance conditions. Those examples show why the name on a branch is not enough to establish its semantics. [1][2]
Write the two paths in plain language
For this example, send a connection request at day 0. If the recipient accepts immediately, wait one day and send a short DM. If no acceptance arrives within seven days, send the email fallback. The email has no additional delay in this example.
If the acceptance occurs on day 3 instead, a production rule that waits one day after acceptance would send the DM on day 4. Beel’s current Accepted preview assumes immediate acceptance; it is not a simulator for every possible event time.
Keep the follow-up relevant to the conversation. The fallback should stand on its own, rather than pretending the recipient has read a LinkedIn message they may never have received.
Separate the acceptance window from the step delay
An acceptance window answers how long to wait for the event. A delay before the fallback answers how long to wait after taking that path. Adding two days to a fallback after a seven-day acceptance window produces day 9, not day 2.
That arithmetic is easy to miss in a visual builder. Review the dates as well as the diagram. If your tool distinguishes “within” from “wait until,” read its condition documentation before assuming the same deadline behavior. lemlist’s guide explicitly describes that distinction. [2]
Try the plan in Beel
Open the public builder, edit the connection request and set the acceptance window to seven days. Connect Accepted to a LinkedIn DM with a one-day wait. Connect Not accepted to an email with no additional wait.
Open Preview and switch between Accepted and Not accepted. The phone compresses each step into two seconds while its date and time advance. Tap a notification to check the complete message; playback pauses while you read.
The preview is local and illustrative. It does not connect a LinkedIn account, observe an actual acceptance, send email or enforce a live stop-on-reply policy.
Decide what happens outside the happy path
Before launching this structure in any production tool, define the cases that a clean diagram leaves out.
- Already connected: decide whether to bypass the request.
- Missing email: define an exit or a task instead of an impossible fallback.
- Late acceptance: decide whether the previous branch remains authoritative.
- Reply on another channel: verify how future steps are stopped.
- Disconnected sending account: make failure visible and assign recovery ownership.
Check responses outside the original branch
A recipient may answer on another channel before the next scheduled message. Amplemarket’s WhatsApp and iMessage documentation, for example, says those replies do not automatically stop its sequence. [3]
Use the same test in any production tool: send a response through each channel you plan to use and inspect the pending actions. Beel’s preview helps review the intended path, but it does not observe actual responses. Assign the live system or person responsible for canceling follow-ups.
Review it with someone who did not build it
Ask a colleague to identify the next message and date for both outcomes. Then change one delay and repeat the question. If they cannot explain the result, simplify the structure or make the timing clearer.
This is a planning check, not a prediction of reply rates. Existing platforms already support conditional outreach; the useful work is making your particular sequence understandable and confirming that its live behavior matches the plan.
Try this in Beel
Put your next sequence on the canvas.
Try the message order, change the waits and preview a branch. Bring a real outreach idea and see how clearly you can explain it in Beel.
Interactive planning demo. Live outreach is in development.Questions people ask
Does a seven-day window plus a two-day email wait mean day 9?
Yes, if the fallback starts when the seven-day window expires and the two-day delay follows it. Confirm the scheduling rules of the live tool.
Does Beel detect real LinkedIn acceptances?
No. You choose an example outcome in the current preview.
What happens if acceptance arrives after the deadline?
That depends on the live tool and your workflow rules. Define and test the late-event case explicitly rather than assuming the recipient changes branches.
Sources
Official documentation consulted for this article. Product availability and terms can change.