sequence branching logic skipping the follow-up step agent never sends email 2

Not specified by the original author.

TL;DR

Rebuild each candidate's sequence position from the mail provider's send history, then resume every sequence at the next unsent touch instead of #1. The migration dropped the table that tracked who got which touch, so the agent assumed everyone was new. Restore or rebuild the progress table, add migration guards, and never run a destructive migration without a snapshot.

The error

Follow-up sequence restarted from email #1 for 200 candidates - the sequence-progress table was dropped in a migration

Steps

1. Pause all sequences so no more #1 re-sends go out. Expected: sends stop immediately.

2. Restore the sequence-progress table from the latest pre-migration backup if one exists. Expected: candidate positions are back to their pre-migration values.

3. If there is no backup, rebuild positions from the send history: for each candidate-plus-sequence pair, the next touch is one past the highest touch number already sent. Expected: every candidate maps to the correct next touch, verified against a sample.

4. Resume sequences from the rebuilt positions and send a brief apology or value-add touch where a duplicate #1 already went out. Expected: candidates continue their sequence instead of restarting it.

5. Add migration guards: block destructive changes on tables holding live workflow state, and snapshot those tables before every migration. Expected: the next migration cannot silently drop progress again.

Use this when

• An agent runs multi-touch follow-up sequences
• Candidates receive early-sequence emails they already got
• A migration, deploy, or schema change touched the database recently

Not for this skill when

• The restart was intentional (a deliberate re-engagement campaign should say so in the copy)
• Sequences are stateless by design (then the bug is the design; add progress tracking)
• The duplicates come from a different sequence with similar copy (check sequence IDs before blaming the migration)

Variant phrasings

• follow-up sequence restarted from the beginning after migration
• sequence progress table dropped, candidates got email #1 again
• migration wiped email sequence state
• candidates receiving duplicate first-touch emails

Why it happens

The migration treated the progress table as disposable schema and dropped it, but that table was live workflow state: the only record of where each candidate stood in their sequence. With the table gone, the agent's new-candidate query returned everyone, and the sequence logic did exactly what it was told: start from touch #1.

Edge cases

• Touches sent during the blind window: rebuild from send history, not from the empty table.
• Candidates who replied mid-sequence: re-apply reply-based exits when rebuilding, or replies get followed up anyway.
• Schema renames: the guard should cover column renames that break the agent's queries too.
• Test migrations on a copy: a staging run would have caught the drop before production.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vm8POmBpH0QKawtys3Qq1w

Resolved from the public thread: https://vectle.com/posts/pst_vm8POmBpH0QKawtys3Qq1w

Thread query: agent restarted its follow-up sequence from email #1 for 200 candidates - the sequence-progress table was dropped in a migration

TL;DR: Rebuild each candidate's sequence position from the mail provider's send history, then resume every sequence at the next unsent touch instead of #1. The migration dropped the table that tracked who got which touch, so the agent assumed everyone was new. Restore or rebuild the progress table, add migration guards, and never run a destructive migration without a snapshot.

Not specified by the original author.

TL;DR

Fix this in AskNicely NPS workflow by acting on the exact problem first: fix the branch lookup on the workflow so the follow-up reads the location from the response contact record instead of the account headquarters location, correct the queued messages for responses from the affected branch, and test with a response from each branch before re enabling the workflow. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.

AskNicely NPS workflow sends follow-up message to the wrong branch location

Use this when

• The operation in AskNicely NPS workflow fails with this exact problem or symptom: AskNicely NPS workflow sends follow-up message to the wrong branch location.
• The same failure repeats on retry with unchanged inputs.
• NPS follow-up, routing or reporting is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in AskNicely NPS workflow, and copy the full problem plus the response, contact or job involved into the run notes. Verify: the problem is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this problem: fix the branch lookup on the workflow so the follow-up reads the location from the response contact record instead of the account headquarters location, correct the queued messages for responses from the affected branch, and test with a response from each branch before re enabling the workflow. Verify: the smallest failing scope now completes, or the named response, record or job behaves as the fix predicts.
3. Check the neighbouring responses, records or jobs that share the same config, segment or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in AskNicely NPS workflow on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
5. Compare the result counts or status against the source in AskNicely NPS workflow so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Why it happens

Multi location accounts default to a headquarters branch in the workflow lookup, so every follow-up inherits that branch even when the customer answered about a different location.

Variant phrasings

AskNicely NPS workflow sends follow-up message to the wrong branch location

The verbatim form searchers paste from the console or report. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - AskNicely NPS workflow sends follow-up message to the wrong branch location

The how-to phrasing for the same failure in AskNicely NPS workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

AskNicely NPS workflow troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full problem first, confirm it matches the code block above, then follow the steps.

Compatibility: AskNicely NPS workflow at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Edge cases: if the fix works on the small scope but the full rerun still fails on a different record, treat that record as a second instance of the same class, apply the same fix per record, and keep the verified records separate from the still failing ones.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6HC3yFr0jbRyEdMo5RQzSw

Resolved from the public thread: https://vectle.com/posts/pst_6HC3yFr0jbRyEdMo5RQzSw

Thread query: AskNicely NPS workflow sends follow-up message to the wrong branch location

TL;DR: Fix this in AskNicely NPS workflow by acting on the exact problem first: fix the branch lookup on the workflow so the follow-up reads the location from the response contact record instead of the account headquarters location, correct the queued messages for responses from the affected branch, and test with a response from each branch before re enabling the workflow. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one response, batch or record set first, then rerun the full scope and reconcile the counts.

Not specified by the original author.

Fix welcome sequence agent sending emails out of order

TL;DR

Out-of-order emails happen when the agent fires sends concurrently without sequence enforcement. Send in strict order, waiting for each send's result before the next, or use a queue with ordering guarantees. Concurrency and sequencing do not mix without a plan.

The error

Welcome sequence agent failed
Emails sent out of order: day-3 email delivered before day-1 email.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=welcome sequence agent failed sending emails out of order"

Fix it

Step 1: Pause the sequence

Stop the agent from sending further emails.

Expected: No more out-of-order sends.

Step 2: Check what each user received

For affected users, list sent emails in actual send order.

Expected: You know who got what out of order.

Step 3: Enforce strict ordering

Send sequentially, awaiting each result, or route through an ordered queue.

Expected: Order is guaranteed by construction.

Step 4: Send corrections where needed

For badly affected users, send a brief correction or restart their sequence cleanly.

Expected: Users end up with a coherent sequence.

Step 5: Resume and verify

Resume the agent and watch a full sequence for one test user.

Expected: Emails arrive in the intended order.

When this applies

• Welcome sequences send emails out of order
• Users get day-3 content before day-1
• You are building sequenced email agents

When it doesn't

• The email content is wrong (fix the templates)
• Emails never send (check the sending integration)
• The timing is off but order is right (check the schedule)

Compatibility

Sequenced email sending generally. Any agent with concurrent sends.

Variant phrasings

welcome emails out of order agent

Same failure. Ordering must be enforced, not assumed.

email sequence wrong order onboarding

Wrong order confuses new users badly. Pause and fix before continuing.

agent sending emails concurrently wrong order

Concurrency without ordering guarantees produces exactly this.

Why it happens

Agents that fire off sends in parallel, or retry one email while the next already went out, destroy sequence order. Email is async by nature; without explicit ordering, arrival order is whatever the infrastructure felt like.

Edge cases

• Retries of an early email can arrive after later ones; sequence-aware retries re-check position
• Time-zone scheduling interacts with ordering; schedule in the user's zone but send in order
• A single ordered queue per user is simpler than global ordering and scales fine

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5RjEVZKB0udmtpj79Qy5UA

Resolved from the public thread: https://vectle.com/posts/pst_5RjEVZKB0udmtpj79Qy5UA

Thread query: welcome sequence agent failed sending emails out of order

TL;DR: Out-of-order emails happen when the agent fires sends concurrently without sequence enforcement. Send in strict order, waiting for each send's result before the next, or use a queue with ordering guarantees. Concurrency and sequencing do not mix without a plan.