معماری چندکسب‌وکاری، تجاری و تجارت الکترونیک · فصل ۴ — IA، Configurator، Lead، Audit و Research · 244
Lead Forms و CRM Handoff
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Lead Forms و CRM Handoff». می‌تواند «Lead Forms و CRM Handoff» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خلاصهٔ درس
workflow تجاری را به UI یا integration منفرد تقلیل می‌دهد و state، rights، approval و measurement را یکپارچه نمی‌کند. موضوع جاری: «Lead Forms و CRM Handoff».
می‌تواند «Lead Forms و CRM Handoff» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
خروجی این درس
می‌تواند «Lead Forms و CRM Handoff» را برای یک workflow محدود با state/contract/approval و verification مناسب طراحی کند.
1) مسئله‌ای که این درس حل می‌کند
پیام «فرم با موفقیت ارسال شد» به‌تنهایی ثابت نمی‌کند lead درست وارد CRM شده است. ممکن است property تغییر نام داده باشد، type عوض شده باشد، consent گم شود یا retry یک duplicate جدید بسازد.
2) مرز درس
خروجی این درس Lead-to-CRM Handoff Contract v1 است. این درس مالک Plan Configurator درس قبل یا Website Audit درس بعد نیست و هیچ CRM واقعی را mutate نمی‌کند.
3) Fact: property فقط label نیست
HubSpot برای CRM property metadataهایی مثل name، label، type، fieldType، options و formField دارد. integration باید به internal property contract تکیه کند، نه به label نمایشی.
4) Fact: lifecycle فرم چند state دارد
در مستندات HubSpot، callbackهای قبل از submit از onFormSubmitted بعد از persistence جدا هستند و server-side submission error هم وجود دارد. پس «کاربر دکمه را زد» با «submission persisted» یکی نیست.
5) Inference: persistence فرم هنوز reconciliation CRM نیست
حتی اگر form submission persisted باشد، هنوز باید ثابت کنیم fieldها به propertyهای درست رسیده‌اند، normalization درست بوده و record مورد انتظار create/update شده است.
6) Design: submission identity را حفظ کن
submission_id باید از شروع handoff تا retry و reconciliation ثابت و قابل ردیابی باشد. retry جدید نباید هویت attempt قبلی را پاک کند.
7) Source intent را از CRM بازسازی نکن
source_page_id و source_intent در لبهٔ وب ثبت می‌شوند. بعداً نباید intent را از lifecycle stage یا labelهای CRM حدس بزنیم.
8) Field-to-property mapping را صریح کن
هر web field باید به CRM property مشخص با type و allowed options فعلی map شود. rename یا schema drift باید state را متوقف کند، نه اینکه silently field را drop کند.
9) Validation و normalization دو چیز متفاوت‌اند
type_validation می‌گوید payload با contract مقصد سازگار است یا نه؛ normalization_result نشان می‌دهد تبدیل واقعی چه خروجی داده. قانون و نتیجه را از هم جدا نگه دار.
10) Consent context را همراه handoff نگه دار
Consent نباید از موفقیت submit یا وجود contact در CRM استنتاج شود. context ثبت‌شدهٔ همان submission باید evidence مستقل داشته باشد.
11) Timeout می‌تواند ambiguous success باشد
اگر request timeout شد، ممکن است CRM قبل از قطع ارتباط record را ساخته باشد. retry کور با CREATE می‌تواند duplicate بسازد؛ dedupe/idempotency و lookup/reconciliation لازم است.
12) Core Evidence Contract
این قرارداد 20 بُعد دارد که 15 بُعد آن critical است. جدول زیر baseline را نشان می‌دهد و فایل JSON/CSV mapping کامل را نگه می‌دارد.
| Submission | Source intent | Mapping | Validation | Consent | Dedupe / retry | Operation | CRM response | Reconciliation |
|---|---|---|---|---|---|---|---|---|
| SUB-244-001 | compare-business-plan | mapped | PASS | present | retry 0 | UPDATE | CRM-RESP-001 | SYNCED |
| SUB-244-002 | request-enterprise-demo | stale property | FAIL | present | retry 0 | REJECT | validation fail | HOLD_MAPPING_DRIFT |
| SUB-244-003 | request-enterprise-demo | mapped | PASS | present | retry 1; prior write ambiguous | UPSERT_OR_RECONCILE | timeout | DEDUPE_RECONCILIATION_REQUIRED |
13) Browser success با CRM response یکی نیست
crm_response_ref باید downstream evidence باشد. success message یا callback فقط یک lifecycle signal است و نمی‌تواند record correctness را جعل کند.
14) SYNCED یک state اثباتی است
فقط وقتی mapping، validation، consent، dedupe، operation، response و reconciliation evidence کافی دارند، state به SYNCED می‌رسد. در غیر این صورت RETRY، MANUAL_REVIEW یا HOLD/BLOCKED حفظ می‌شود.
15) Lab و Transfer
Lab هشت fixture و 48 assertion دارد. در transfer، property جدید required می‌شود، enum گزینه‌های تازه می‌گیرد و retry بعد از success پنهان رخ می‌دهد. mapping و dedupe را از evidence جدید recompute کن؛ baseline را copy نکن.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
COM-003-S1 retrieval
What does COM-003 own, and why is a browser/form success event insufficient to prove CRM handoff correctness?
COM-003-S2 application
Build Lead-to-CRM Handoff Contract v1 for the baseline synthetic submission.
COM-003-S3 diagnosis
A CRM property internal name changes and a request timeout may have followed a successful write. Which states block blind retry and what evidence repairs them?
COM-003-S4 transfer
A lifecycle-stage property becomes required, an enumeration changes, and a retry arrives after hidden success. Recompute mapping, validation, dedupe and reconciliation from current evidence.
ملاک‌های ارزیابی (rubric)
Blocking dimensions: submission/source identity, current field-property map, type validation, normalization result, consent context, dedupe key, operation, CRM response, retry history, reconciliation state, owner and evidence. A browser success event cannot compensate for missing downstream reconciliation evidence.
منابع و تازگی
مطالعهٔ موارد (case studies)
A plan form maps stable internal fields to current CRM properties and reconciles to one existing contact.
The website keeps sending an old CRM internal property name after the CRM property was renamed.
A lifecycle-stage property becomes required, enum options change, and a retry arrives after a hidden successful write.
تصاویر درس
Validated payload flows through mapping, normalization and consent, dedupe, CRM operation and response, then reconciliation to synced or typed non-success states.
فایل‌های آزمایشگاه
python run_checks.py را اجرا کنید. هشت fixture مصنوعی drift نگاشت property، type/required validation، consent، retry مبهم و dedupe، response downstream و transfer را تست می‌کنند. شبکه، API key یا دادهٔ مشتری لازم نیست.