Good — that's already the safe default in the enroll path: a contact already in another sequence returns

IN_OTHER_SEQ

and is left where it is (never force-moved into Cequence), and opted-out contacts are skipped too. Let me confirm the running enroll is behaving that way and see the status spread so far: Checked enroll status tally + whether IN_OTHER_SEQ are skipped Wait — your instruction surfaces a real risk I need to handle immediately. The custom fields (

Personalisation

,

Job Posting

, etc.) are account-level and shared across sequences. The running enroll imports with

overwriteExisting=True

, so any of these 377 who are active in another sequence (e.g. VDL) would have their shared fields overwritten with Cequence content — corrupting their other sequence's emails. I'm stopping the enroll now before it does more of that: Stopped. Now I need to assess the blast radius before doing anything else. The

enroll_csv

runs the bulk import (overwrite=True) first, then the enroll loop — so the import may have already overwritten fields. The real exposure is only contacts active in another sequence that reuses these shared fields. Let me check: did the import overwrite all 377, and are the touched contacts in other active sequences? Assessed overwrite extent + sequence membership of touched contacts All 7 checked show

sequences=[]

and — notably — Personalisation does not match the Cequence content, suggesting the overwrite may not have taken. But gotcha #17 warns the

sequences

field reads

[]

for paused sequences, so I can't trust it blindly. Let me verify its reliability against a known active-VDL contact, and check the real overwrite state of the sample: Tested sequences-field reliability + sample overwrite state Two key facts: (1) the

.sequences

field is unreliable — a known active VDL contact also shows

[]

, so I can't use it; (2) the import did overwrite the sample (the

None

ids fooled my earlier check, but the values are clearly Cequence content). So I need the authoritative cross-reference. Let me first quantify the damage (did the stopped enroll's bulk-import overwrite all 377?) and scope the active sequences: Damaged check + active-sequence scope This is a real problem I need to own. The bulk import overwrote all 377 contacts' shared account-level fields, and there are 83 active sequences (Affix, Flotiq, Aexus, Simreka, S4U…) all using the same canonical container fields. Any of my 377 who are active in those would have had their other campaign's personalization clobbered. I have to quantify the overlap authoritatively (the

.sequences

field is broken). Let me cross-reference my 377 against every active sequence's enrolled contacts:

Hello Hessan, I appreciate you sharing this! Please let me check this and update you.

the bottom line is, working with API is very messy. is it due to my legacy plan? or can API be reliably used with a different plan?

Thanks for waiting! The subscription plan doesn't affect API performance. You mentioned that when you use the API to import or update contacts, it overwrites your custom fields (like "Personalisation," "Job Posting") — and because those fields are shared by the contact across every sequence, the overwrite quietly changes the wording of emails the contact is set to receive in other sequences they're already in. What our technical team confirmed is true - A contact's custom fields are stored once per contact, shared across all their sequences. There's no separate copy per sequence. - Importing with the "*overwrite*" option turned on replaces those field values outright. (With it off, it only fills in blanks and leaves existing values alone.) - Emails pull the field values at the moment they send, not when the contact was added. So if a field gets overwritten before an email goes out, that email goes out with the new (wrong) text — even in a different sequence. - Bottom line: yes, an overwrite import can corrupt the personalization of emails queued in a contact's other sequences. Behavior we couldn't confirm: - API doesn't skip or protect a contact already in another sequence. By default, it just adds them anyway — there's no such protection built in. (Opted-out contacts are skipped, but silently.) A custom field is one field per contact, shared everywhere. Overwriting it through the API is the exact same thing as opening the contact and editing that field by hand — it changes for every sequence, because there's only one copy. The "overwrite" import option followed its built-in logic in this case. It would behave the same way if we changed the data in a custom field manually. To make sure we fully understand your expectations, could you let us know what behavior you would ideally expect in this scenario?

i need a solution in order to for variables to stay for 1 prospect only and not change other prospects. im running hyper personalised sequences. that means for example 100 people will receive 800 different emails in a 8 step sequence, for this i need variables that are specific for each prospect and do not change any other prospect

Could you please elaborate a bit more on this? If you are updating a prospect via API with overwrite, your custom field data will be changed in all sequences because it's the same prospect.

@Tania: What we run (the use case): We send hyper-personalized sequences. Every prospect receives a unique, individually-researched email at every step — not one shared template with a few merge tags. One 8-step sequence to 100 prospects = 800 distinct emails, all different. We deliver this by storing each prospect's bespoke per-step bodies in custom fields (

{{Personalisation}}

, `{{Step2}}`…`{{Step8}}`,

{{Subject}}

) and making each sequence step just that one variable. In our model, the variable value IS the personalized email. The exact conflict (using your team's three confirmed facts): 1. A custom field is storedonce per contact, shared across every sequence— there is no per-sequence copy. 2. Emails resolve field valuesat send time, not at enrollment. 3. The same prospect is routinely inmore than one of our sequencesover time (re-engagement, different products, different waves) — and each sequence needs_different_bespoke content for that prospect. Combine these: because there is only one copy of

{{Personalisation}}

per contact, a prospect cannot hold different personalized content in two sequences. The moment we load Sequence B's content for that prospect, Sequence A's already-queued emails silently begin sending Sequence B's text. So a normal import/update for one campaign corrupts the personalization of every other sequence that prospect is enrolled in. Why this is a structural blocker, not a usage mistake: Reply's variable model assumes personalization = a few stable attributes (FirstName, Company) that are identical in every sequence. That holds for template outreach. It is fundamentally incompatible with content-level personalization, where the entire body is a variable that must differ per sequence. There is currently no way to scope a variable's value to a sequence or to an enrollment. What we need (any one of these solves it): 1. Sequence-scoped / enrollment-scoped custom-field values— the same contact holds a different`{{Personalisation}}`in Sequence A vs Sequence B.(Ideal.) 2. Snapshot content at enrollment— when a contact is enrolled, the referenced field values (or rendered step content) are frozen for that enrollment, so a later field update can't rewrite already-queued emails. 3. A per-enrollment content payload— let us pass the 8 bespoke bodies_with the enrollment API call_, stored immutably against that contact-in-that-sequence, independent of the global custom fields. Today's only workaround is untenable: before every import we must cross-reference the entire audience against all ~80 of our active sequences and exclude anyone who overlaps — which loses reach, is fragile, and still leaves no way to run one prospect in two personalized campaigns at once. Could you raise this with product/engineering as a feature request and tell us whether any of the three options is feasible or on the roadmap? This is the single thing blocking us from scaling hyper-personalized sequences on Reply.

Hi Hessan, thank you for explaining this in detail. I understand the use case. Since custom fields are currently contact-level and shared across sequences, I’ll check with our technical team if any of the options you mentioned would be possible to raise as a feature request. I’ll get back to you once I have more information from the team.

Hey @Hessan Haiderzada, Two quick questions/suggestions: 1. Could you elaborate on cases where one contact is added to more than one active sequence at a time? Is it for running outreach across different projects or clients to the same contact? If so, switching to an agency account structure with separate workspaces per project/client should solve this - each project/client would have its own isolated database of contacts, sequences, etc. 2. You may want to consider creating unique contact custom fields per sequence. For example, instead of using {{Personalization}}, you could use {{Personalization_SequenceA}} and {{Personalization_SequenceB}} - this keeps things cleaner and avoids any overlaps. Let me know if you'd like to hop on a quick call and discuss.

@Max Foster hanks Max — quick answers: On #1 (workspaces): the overlap is almost always within a single client, not across clients. The same buyer is in, say, a re-engagement sequence and a new-product/new-wave sequence for the same client, each needing different bespoke bodies. Separate workspaces isolate clients, so they wouldn't separate two sequences inside one client — and a workspace-per-sequence setup isn't practical at ~80 sequences (duplicated senders, domains, warmup, reporting). So this doesn't resolve the core collision for us. On #2 (per-sequence fields): agreed — this is the workable path today, and we're adopting it: each sequence references its own field-set (

{{Personalisation_A}}

,

{{Step2_A}}…

, etc.) so loading one sequence's content can't overwrite another's. To make it scale we'll reuse a small pool of field-"slots" across non-overlapping sequences rather than one set per sequence. Two questions so we can size it: 1. What's thecustom-field capper account (and does it differ by plan)? 2. Can custom fields becreated via the API(e.g.

POST /v3/custom-fields

)? We'd auto-provision the slot fields. The ideal fix is still enrollment-scoped values or snapshotting content at enrollment — thanks for flagging it to engineering; we'd love to know if either lands on the roadmap. Happy to hop on a call.

Hey @Hessan Haiderzada, • Yes, you can absolutely create and update custom fields via API - and make them available across the entire organization, if you prefer. • The default limit is 50 custom fields per account. Would you need more than that? • Honestly, I think it'll be much cleaner and more manageable to create a unique set of personalization fields per sequence. Otherwise it can get messy quickly and it becomes hard to track where content is coming from.

@Max Foster Perfect, that helps. Two things: On the 50-field cap — yes, we'll need more. We're already at ~49/50 on this account, and content-level personalization needs ~9 fields per "set" (Subject + Personalisation + Step2–Step8). One-set-per-sequence doesn't scale for us — at ~80 sequences that'd be ~720 fields — so we're not going that route. Instead we reuse a small pool of field-"sets" across sequences that don't share prospects, and recycle a set once a sequence finishes. The number we need = the max sequences a single prospect is in simultaneously (a handful), plus headroom. Could you raise the cap to ~150? And can we delete custom fields via the API to reclaim the legacy ones we no longer use? On tracking: agreed that ad-hoc field reuse gets messy — we'll manage the set↔️sequence↔️content mapping programmatically on our side, so provenance stays clean. Also good to know fields can be org-wide — we'll keep the personalization sets account-scoped for now. Thanks Max, this unblocks us.

Hey @Hessan Haiderzada • just a heads-up - your current account doesn't support the full Agency structure (Organization) with separate workspaces per client/project. You can create a new account to test that out. We'll likely have a migration option for legacy accounts like yours by end of year. • I've increased the custom fields limit in your account to 150 as a courtesy. • On deleting custom fields via API - yes, that's possible, but typically only when no contacts have values stored in those fields.