CPPA = cererea de ștergere/mascare a datelor unui client. Fluxul: verifici identitatea clientului (IRIS · Epsilon · Snowflake) → unmerge → CCPA + GDPR → validezi că e curat → maschezi BP-urile → închizi ticketul. Un CPPA generează mai târziu și ticket EDW (+ Epsilon) pe același email.
Termen (SLA) — 45 de zile: cele 3 tickete ale aceluiași email (CPPA + EDW + Epsilon) au un singur termen comun = data deschiderii ticketului CPPA + 45 de zile calendaristice. Toate trebuie închise până atunci. Urmărește cât mai e: ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = termen depășit.
Deschizi ticketul (caută după număr TASK…). Notează emailul clientului și numele (first + last) din descriere.
Ce decizi
Emailul e cheia întregului flux — cu el cauți în toate celelalte sisteme.
1.1Preia ticketul (la începerea lucrului):
Assigned to = Ion Mustafenco.
Status = Work in Progress.
Click pe Update (dreapta sus).
Preluare ticket: Assigned to = Ion Mustafenco, Status = Work in Progress → Update.
2 Caută clientul în IRIS
Întâi — caută emailul în ServiceNow: înainte să începi procesarea, iei emailul din ticket și îi dai search în ServiceNow → vezi toate ticketele care apar ca rezultat pe acel email.
Verifici dacă nu există tickete de unmerge, sau altă problemă legată de acest cont / email.
Dacă există un unmerge (sau altă problemă) → mai întâi te clarifici cu acel ticket (îl rezolvi / aștepți) și abia apoi treci la procesul CPPA.
ServiceNow: search după email → toate ticketele legate (Campaign / EDW / historical DB / CMA-WCS) — verifici dacă nu e vreun unmerge sau altă problemă înainte de CPPA.
uid (= CDP ID, îl folosești la unmerge și GDPR), loyalty id-uri (zloyid), zwcs (logon ids / emailuri de logare), eventual PLCC (card de credit). Plus numele.
Ce decizi
Verifici că numele din IRIS = numele din ticket. 0 rezultate = clientul nu e în IRIS.
Căsătorie / middle name: dacă numele nu se potrivește perfect, poate fi schimbare de nume după căsătorie sau middle name. Match pe first name + o parte din last name = ok (ex. „Andrew Place-O Hern" în ticket vs „Place-O Hern" în sistem).
zwcs same-person: dacă un logon id/zwcs e pe alt email, dar numele clientului apare în acel email (ex. Trevor Randall → trandall@…), e aceeași persoană → ok, continui.
PLCC activ → Dalton: dacă clientul are card PLCC (TSC credit card) activ, cererea NU se poate îndeplini — nu ștergi/maschezi nimic. Reasignezi ticketul la Dalton:
Assignment group = Customer Privacy Compliance.
Assigned to = Dalton Holladay.
Status = Open.
Scrii comentariul în Work notes (Internal) → apeși Post.
Apoi Update (salvezi reasignarea).
Q-TOK1 — verifică dacă PLCC e activ (rulezi cu token-urile PLCC din IRIS)
SELECT * FROM MKT_DB.STG_REPL_TALEND_ODS.CDP_CONSUMER
WHERE POS_TOKEN IN ('<token_plcc>')
Ce înseamnă: token-urile PLCC le iei din IRIS. ≥1 rând = card PLCC ACTIV → reasignezi la Dalton (vezi comentariul de mai jos). 0 rânduri = fără PLCC activ → continui fluxul normal.
Comentariu la reasignare — Work notes (Internal), apoi Post
customer have active tsc credit card and cannot fullfill ccpa request by design when active
Variantă (ca în screenshot) — poți include numărul cardului: customer have active tsc credit: "<credit card number>", and cannot fullfill ccpa request by design when active.
Reasignare PLCC: Assignment group = Customer Privacy Compliance, Assigned to = Dalton Holladay, Status = Open, comentariul în Work notes (Internal) → Post.
3 Verifică loyalty-ul și identitatea în Snowflake
Unde
Snowflake (client SQL)
Ce faci
Rulezi Q-LOY cu loyalty id-urile (loyid) din IRIS — confirmă că numele de pe loyalty = clientul.
Q-LOY — un sales record per loyid (rank=1)
SELECT * FROM (
SELECT ROW_NUMBER() OVER(PARTITION BY loyid ORDER BY trandate,idnumber,fname,lname) AS tran_rnk, *
FROM (
SELECT trandate, loyid, fname, lname, adrs1, city, state, zip, email, phnum1, phnum2, idnumber
FROM MKT_DB.STG_MARKETING.VW_ZSALES_HEADER
WHERE loyid IN ('7700000000000001')
) a
) b
WHERE tran_rnk = 1
ORDER BY loyid
Exemplu rezultat
LOYID
FNAME
LNAME
EMAIL
STATE
IDNUMBER
7700000000000001
JOHN
DOE
JOHN.DOE@EXAMPLE.COM
MI
10000000001
Ce înseamnă: numele de pe loyalty = clientul din ticket → identitate confirmată. IDNUMBER = cheia ZWCS/POS (vezi unmerge).
Ce faci
Dacă IRIS arată token-uri PLCC, rulezi Q-TOK1 — trebuie 0 rânduri ca să poți procesa.
Q-TOK1 — token PLCC în CDP_CONSUMER (trebuie 0 rânduri)
SELECT * FROM MKT_DB.STG_REPL_TALEND_ODS.CDP_CONSUMER
WHERE POS_TOKEN IN ('<token>')
Ce înseamnă:0 rânduri = fără PLCC activ → procesezi normal. ≥1 rând = card activ → Dalton (vezi regula de la pasul 2).
Rulezi căutarea Epsilon după email — vezi dacă emailul are profil(e) de loyalty.
Epsilon — profile după email (PROFILE_EXTRACT)
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
Exemplu rezultat
PROFILE_ID
CARD_NUMBER
FIRST
LAST
EMAIL
STATUS
11111111-…-555555555555
7700000000000001
Hannah
Garey
john.doe@example.com
A
Ce înseamnă:profile_id = ce se va trimite la ștergere în fluxul Epsilon. STATUS: A=activ, I=inactiv, D=șters. 0 rânduri = emailul nu mai e în Epsilon.
Mai multe loyalty pe emailuri diferite = același client: dacă găsești mai multe loyalty id care aparțin aceluiași client dar sunt pe emailuri diferite, atunci toate loyalty-urile trebuie trecute sub emailul din ticket. În Epsilon admin editezi fiecare profil și pui ca adresă de email emailul din ticket.
Emailuri „victim" (nu se pot edita): unele profile sunt de tip victim — pe astea NU le poți edita direct. În acel caz:
Găsești survivor profile-ul (profilul care a „supraviețuit") și verifici dacă aparține clientului din ticket.
Dacă survivor-ul aparține clientului din ticket → survivor-ul trebuie să aibă emailul din ticket.
Salvezi separat ambele loyalty id (survivor + victim) — o să-ți trebuiască mai târziu pentru ticketele Epsilon (ex. de pus ca +pid victim).
[Screenshot] Epsilon admin — profilul găsit după email
Iei CDP ID-ul clientului din IRIS — Account Details → CDP ID (ex. 6164210560). Apoi click pe Unmerge Toolkit (meniul Toolkits, stânga).
IRIS: iei CDP ID din Account Details, apoi Toolkits → Unmerge Toolkit.
5.2
Creezi un fișier CSV cu un singur rând = CDP ID-ul (fără header) și-l salvezi ca unmerge1.csv.
Exemplu conținut unmerge1.csv
6047589403
5.3
Choose File → selectezi unmerge1.csv → apeși Upload User Data.
Unmerge Toolkit: Choose File (unmerge1.csv) → Upload User Data.
Ce vezi
După upload apare un rezultat / confirmare (de forma File 'unmerge1_…csv' uploaded…; procesarea în backend poate dura).
Ce decizi
Pui rezultatul de după upload în comentariul ticketului din ServiceNow (dovada că unmerge-ul a fost trimis). Apoi continui.
Unmerge manual prin Zeta: dacă pentru cazul ăsta ai făcut deja unmerge manual prin Zeta (vezi scenariul 3 de la validare), atunci unmerge-ul prin Toolkit (pasul ăsta) NU mai trebuie făcut — e deja rezolvat.
6 CCPA + GDPR (împreună)
⏰ CCPA + GDPR SE FAC LA MINIM 24 DE ORE DUPĂ UNMERGE (pasul 5). NU în aceeași sesiune — unmerge-ul trebuie întâi procesat în backend; dacă faci CCPA+GDPR imediat, datele nu se curăță corect. Deci: unmerge azi → CCPA + GDPR mâine (sau mai târziu).
CCPA și GDPR se fac împreună, în același pas. CCPA curăță SAP CRM; GDPR curăță IRIS/Zeta (durabil). Unul fără celălalt lasă date.
De unde
Ambele toolkit-uri se deschid din IRIS → meniul stânga Toolkits → CCPA Delete Toolkit / GDPR Delete Toolkit.
IRIS → Toolkits → CCPA Delete Toolkit și GDPR Delete Toolkit (comun pentru pasul 6a și 6b).
Iei CDP ID-ul LIVE din IRIS (re-caută emailul acum). În câmpul „Enter CDP User ID(s)" pui CDP ID-ul direct (nu fișier; mai multe = separate prin virgulă) → Upload into Toolkit.
Ce vezi
Apoi Fetch Stats (cu interval de date) → confirmi Verify_Delete_CDP = Y (jobul rulează zilnic, nu e instant).
GDPR NU se menționează în ticket. Ștergerea GDPR se face, dar în comentariul oficial ServiceNow scrii doar partea CCPA standard. Fără notă de GDPR.
CDP ID ≠ uid vechi: profilul se re-materializează — ia mereu CDP ID-ul LIVE din IRIS înainte de delete, nu cel notat la pasul 2.
GDPR PROD Delete Toolkit: Enter CDP User ID(s) (direct, separate prin virgulă) → Upload into Toolkit → „Success: File … uploaded successfully"; apoi pui From/To Date → Fetch Stats → Verify_Delete_CDP = Y.
Fetch Stats = ce s-a încărcat recent (pe interval de date): după upload, pui From Date / To Date și apeși Fetch Stats — îți arată ce a fost încărcat în acel interval (CCPA / GDPR), ca să confirmi că upload-ul tău a intrat și să citești statusul (la GDPR: Verify_Delete_CDP = Y). Pune intervalul care acoperă ziua în care ai făcut upload-ul.
7 Validare — clientul e curat (IRIS · CRM Search · BI Team)
⏰ VALIDAREA SE FACE LA MINIM 24 DE ORE DUPĂ CCPA (mascare + cleanse). NU în aceeași zi — datele au nevoie de timp să se proceseze în backend. Flux termen: unmerge → (24h) → CCPA + GDPR → (24h) → validare. Dacă validezi mai devreme, rezultatele pot fi false.
Cauți emailul (Customer Search) → No rows / 0 rezultate. În plus, verifici fiecare BP din ticket în IRIS să nu mai fie prezent — caută BP-ul și cu 0, 00, 000în față (uneori ID-ul e stocat cu zerouri în față), ca să fii sigur că nu apare sub nicio formă.
CRM Search
În SAP CRM, Identify Customer (rol Z_CSC_LOY), pui emailul în E-Mail Address → Search Account → trebuie „Result List : 0 Accounts Found".
BI Team
În SAP CRM, Search: Customers (rol BI), cauți după email → 0 rezultate.
Cum citești:0 rezultate = curat; ≥1 = încă există date → investighează / repetă mascarea.
CRM Identify Customer → căutare după email → Result List : 0 Accounts Found.BI Team Search: Customers → criteriu E-Mail → Result List gol (0 rezultate).IRIS Customer Search → după email (sau BP, cu 0/00/000 în față) → No rows.
Scenariu 1 — BP încă apare în IRIS, contul e al userului din ticket: dacă la validare BP-ul mai apare în IRIS și contul aparține aceluiași client din ticket (numele/emailul confirmă) → datele nu s-au șters durabil. Reporni CPPA + GDPR pe acel client: reiei fluxul de la CCPA + GDPR Delete Toolkit (pasul 6) — CDP ID LIVE din IRIS → upload în ambele toolkit-uri (CCPA + GDPR, la pachet) → apoi re-validezi aici. (Profilul se poate re-materializa între timp, de aceea ia mereu CDP ID-ul live.)
Scenariu 2 — BP în IRIS cu divergențe, cont INACTIV: dacă BP-ul mai este în IRIS, contul are divergențe față de ticket (minore / medii / majore — ex. CHRIS ROBERGE în IRIS vs. Cooper Roberge în ticket), iar contul din IRIS e Inactive (cu sau fără email) → pui emailul din ticket pe contul din IRIS și reporni CPPA + GDPR.
Condiție obligatorie: contul IRIS trebuie să fie Account Status = Inactive. Dacă e activ → NU faci asta (e alt client / cont viu).
Pui emailul din ticket: în IRIS, tab-ul Communication → Add New Contact → Contact Method Email, Contact Value = emailul exact din ticket → salvezi. (Dacă emailul din ticket există deja pe cont, doar confirmi; dacă lipsește, îl adaugi — obligatoriu.)
Apoi reiei pasul 6 (CCPA + GDPR Delete Toolkit, CDP ID live) și re-validezi aici.
IRIS: Account Status = Inactive → tab Communication → Add New Contact ca să pui emailul din ticket.Ticketul: iei emailul exact (și numele) din descriere — aici Cooper Roberge, divergent de CHRIS ROBERGE din IRIS.
Scenariu 3 — BP în IRIS, contul e al ALTEI persoane și e ACTIV: dacă BP-ul mai e în IRIS, dar contul aparține exclusiv altei persoane (nu clientului din ticket) și e Active → NU reporni CPPA/GDPR și NU pui emailul din ticket pe el. E nevoie de investigare suplimentară + unmerge manual prin Zeta. (Pașii concreți pentru acest caz se definesc ulterior.)
8 Scoate BP-urile (Q1)
Unde
Snowflake
Ce faci
Rulezi Q1 cu emailul → lista BP-urilor (Business Partners) ale clientului.
Q1 — extract BPs după email
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
ORDER BY CUST_COMM_CHAN_END_DATE
Exemplu rezultat
SAP_BP_ID
METHOD
EMAIL_ADDR
END_DATE
8006008501
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
8006873009
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
Ce înseamnă: fiecare SAP_BP_ID = un BP de mascat. END_DATE = 9999-12-31 = înregistrare activă.
Scoate doar BP-urile UNICE: Q1 poate întoarce multe rânduri (ex. 20+), dar multe sunt duplicate — același SAP_BP_ID apare de mai multe ori (activ + inactiv, pe perioade diferite). Iei doar valorile unice de SAP_BP_ID — acelea sunt BP-urile de mascat.
Când validarea (pas 7) e curată, postezi mesajul de mai jos în ticket și închizi ticketul CPPA. (GDPR NU se menționează.)
Mesaj la close — CPPA (un singur BP)
<email> changes have been validated in CRM and IRIS/ZETA.
BP: <BP>
Mesaj la close — CPPA (mai multe BP-uri)
<email> changes have been validated in CRM and IRIS/ZETA.
BPS: <bp1>, <bp2>, <bp3>
De aici continuă pe ticketul EDW: extragerea BP-urilor, mascarea și verificarea (Q2/Q3) se fac în fluxul EDW → vezi tabul EDW.
EDW = scoaterea clientului din raportarea EDW. Pornești de la BP-urile clientului (același email ca la CPPA): le extragi (Q1), le maschezi în SAP CRM, apoi verifici (Q2/Q3) și închizi. 🔗 Deschide coada EDW în ServiceNow — ticketele „…completely removed from EDW reporting".
Termen (SLA) — 45 de zile: ticketul EDW împarte același termen cu CPPA și Epsilon ale aceluiași email: data deschiderii CPPA + 45 de zile calendaristice (nu de la deschiderea EDW). ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = depășit.
1 Scoate BP-urile (Q1)
Unde
Snowflake
Ce faci
Rulezi Q1 cu emailul → lista BP-urilor (Business Partners) ale clientului.
Q1 — extract BPs după email
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
ORDER BY CUST_COMM_CHAN_END_DATE
Exemplu rezultat
SAP_BP_ID
METHOD
EMAIL_ADDR
END_DATE
8006008501
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
8006873009
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
Ce înseamnă: fiecare SAP_BP_ID = un BP de mascat. END_DATE = 9999-12-31 = înregistrare activă.
Scoate doar BP-urile UNICE: Q1 poate întoarce multe rânduri (ex. 20+), dar multe sunt duplicate — același SAP_BP_ID apare de mai multe ori (activ + inactiv, pe perioade diferite). Iei doar valorile unice de SAP_BP_ID — acelea sunt BP-urile de mascat.
Mascarea se face prin SAP Logon, pe rolul de business ZTSCMKTPRO – BI Team. Pașii concreți:
Intri pe rolul ZTSCMKTPRO – BI Team. La selecția rolului de business, alegi ZTSCMKTPRO - BI Team.
Selectează rolul ZTSCMKTPRO - BI Team.
Navighezi la Accounts. Din dropdown-ul Home (dreapta sus) → Accounts & Products; apoi în blocul Search → Accounts.
Dropdown Home → Accounts & Products.În Search → Accounts.
Cauți BP-ul după Account ID. În Search: Customers, pui criteriul Account ID = BP-ID-ul (ex. 425288382) → Search. În Result List dai click pe nume → intri în profil.
Criteriu Account ID = BP-ID → Search.Click pe nume (ex. JOHN DOE) → deschide profilul.
Apeși Edit și maschezi datele. În profil, dreapta sus → Edit (pagina trece în modul editare). Apoi golești toate câmpurile de identitate și pui Last Name = DONOTUPDATE. La final profilul trebuie să arate DOAR Last Name = DONOTUPDATE (restul gol), ca în exemplu:
Golești: First Name, Middle Name, Search Term, Correspondence lang., Street/House Number, Postal Code/City, E-Mail.
Last Name = DONOTUPDATE.
Dreapta sus → Edit.Exemplu rezultat: Last Name = DONOTUPDATE, celelalte câmpuri golite.
4.1 Scrolezi în jos la tabelul Communication Table → click pe Edit List (dreapta sus).
În Communication Table → Edit List.
4.2 Dai click pe un rând → apeși Delete (coșul, dreapta sus). Repeți până nu mai rămâne niciun item în tabel (atenție: poate fi mai mult de o pagină — vezi Back / 1 2 / Forward jos).
Selectezi rândul → Delete (coș), până golești tabelul.
4.3 Când tabelul e gol, apeși Insert. La Communication Method alegi unul din cele 3 phone methods: Work Phone, Cell Phone sau Home Phone. În câmpul Phone pui 0000000000.
Tabel gol → Insert.Method = un phone method; Phone = 0000000000.Exemplu rezultat: un singur rând (ex. Work Phone) cu telefon mascat.
4.4 În pagină dai Ctrl+F și cauți do not — sunt 8 checkbox-uri „Do Not…" → le bifezi pe toate (sunt pe tabul Demographics):
Do Not Update - Name · Do Not Update - HH · Do Not Update - Addr · Do Not Contact Mail
Do Not Call Work · Do Not Call OTHER · Do Not Call HOME · Do Not Call CELL
Save-ul a reușit când butonul Save DISPARE. Dacă rămâne după click → nu s-a salvat: verifici cauza (jos-stânga apare o eroare, ex. „Enter a postal code") → o rezolvi și salvezi din nou.
Save / Cancel (jos-dreapta).Dacă nu dispare: eroarea jos-stânga spune de ce (ex. „Enter a postal code").
Cleanse — se face separat prin SAP Logon (SAP GUI desktop), în CRM PC1 (Production).
5.1 Deschizi programul SAP Logon (de pe desktop).
5.2 Din listă (Connections) alegi CRM PC1.
5.3 Introduci credențialele: user <user> + parola → Enter.
SAP Logon → CRM PC1 → login (user <user>). Atenție: e mediul PRODUCTION.
5.4 În câmpul de comandă (sus-stânga) scrii sa38 → Enter.
Câmp comandă → sa38 → Enter.
5.5 La Program scrii ZMC_switch_cleanse_status → apeși F8 (sau meniu Program → Execute).
Program = ZMC_switch_cleanse_status.F8 sau Program → Execute.
5.6 În ecranul „Switch customer cleansing status": la Business Partner pui BP-ID-ul; scoți bifa de la Test Run; la Max number of dialogs pui 5. (Cleansing Status rămâne CLEANSED.)
BP-ID + Test Run debifat + Max dialogs = 5.
5.7 Apeși F9 (sau meniu Program → Execute in Background) — cleanse-ul rulează ca job în background.
F9 / Program → Execute in Background.
5.8 Apare dialogul Background Print Parameters → click pe bifa verde (confirm). Jobul de cleanse e trimis.
Background Print Parameters → bifa verde (confirm).
5.9 Apare dialogul Start Time → click pe Immediate (apoi Check / salvează) — jobul pornește imediat.
Start Time → Immediate.
5.10 Cu Immediate Start bifat, apeși butonul Save (dischetă, lângă Check) — jobul de cleanse e programat și pornește imediat.
Immediate Start → Save (dischetă).
Unlock BP (după situație) — lock agățat în SAP: dacă la deschiderea/editarea BP-ului SAP zice „being processed by user…", înseamnă că o sesiune anterioară (mask/WebGUI) nu s-a închis curat și a lăsat un lock agățat pe partener. Îl ștergi din SM12 (pașii de mai jos). ⚠️ Ștergi DOAR lock-ul tău — un lock pe alt user = chiar editează cineva acum, nu-l atinge.
Înainte de unlock: închide întâi tab-ul BP-ului respectiv din CRM (fereastra/sesiunea unde era deschis partenerul). Dacă-l lași deschis, lock-ul se pune la loc imediat după ștergere (sau rămâne inconsistent). Întâi închizi tab-ul BP-ului, apoi faci pașii de mai jos.
U.1 În SAP Logon, în câmpul de comandă (okcode) scrii sm12 → Enter.
SAP Logon: în câmpul de comandă scrii sm12 → Enter.
U.2 În ecranul Select Lock Entries, la Table name scrii BUT000 → Enter. (User Name e deja userul tău; lași Client-ul cum e.)
Select Lock Entries: Table name = BUT000, User Name = userul tău → Enter.
U.3Execute (F8) → se afișează Lock Entry List.
U.4 Vezi un rând cu lock-ul tău: User Name = userul tău, Table = BUT000, iar Lock Argument = identificatorul blocat (ex. 1000434502249). Îl selectezi (jos scrie „Selected Lock Entries: 1").
U.5 Apeși pe iconul Delete (coș de gunoi) din bara de sus (echivalent cu Lock Entry → Delete).
Lock Entry List: selectezi rândul cu lock-ul tău (Lock Argument = identificatorul blocat) → apeși iconul Delete (coș).
U.6 La dialogul „Delete lock entry?" apeși Yes.
Dialog „Delete lock entry?" → Yes.
U.7 Dacă apare mesajul „The lock entry has been manually deleted (transaction SM12)." → e OK, lock-ul e șters. Închizi fereastra. Acum poți redeschide/edita BP-ul normal.
Confirmare: mesajul „The lock entry has been manually deleted (transaction SM12)." = deblocarea a reușit. Dacă apare, îl închizi — e tot OK.
Mesaj „The lock entry has been manually deleted (transaction SM12)." → deblocarea a reușit, închizi fereastra.
BP nu apare în BI search: BP inexistent / deja curat = reziduu istoric → skip (nimic de mascat, mai ales dacă Q2 e valid). Dacă Q2 e invalid dar BP-ul tot nu se găsește în BI Team (nu-l poți masca) → „accept reziduu" și la close folosești mesajul dedicat de la pasul 4 („BP negăsit în BI Team / reziduu").
Mesaj după mascare (postat în ticketul EDW)
Data processed for: <bp1>, <bp2>.
Waiting 48-72Hrs for data to process and proceed with validation
După mascare + cleanse postezi acest mesaj și aștepți 48–72h până verifici (pas 3). Dacă remaschezi mai târziu, folosești varianta „Data processed again for: …".
3 Verifică mascarea (BI Team + Q2 + Q3)
⏰ VERIFICAREA SE FACE LA MINIM 24 DE ORE DUPĂ MASCARE + CLEANSE. NU în aceeași zi — datele au nevoie de timp să se proceseze (de-aia mesajul „Waiting 48-72Hrs…"). Dacă verifici prea devreme, BI Team / Q2 / Q3 pot arăta fals nemascat.
Mai întâi re-verifici în BI Team: cauți BP-ul și deschizi profilul, și confirmi că:
Name = DONOTUPDATE (first/middle/search term goale);
Phone = 0000000000 sau deloc (fără telefon);
fără alte date — fără adresă, fără email, fără alte câmpuri completate.
Dacă ceva din astea nu-i curat → mai maschezi odată (vezi pas 2) înainte să treci la Q2/Q3.
Exemplu rezultat BUN în BI Team: Name = DONOTUPDATE, Phone = +1 (000000000), fără street/city/region/email.
Email = 0
Apoi cauți emailul și confirmi că nu mai apare nimic: în Identify Customer (rol Z_CSC_LOY) → Result List : 0 Accounts Found; și în BI Team Search: Customers după email → 0 rezultate.
IRIS
Aceeași validare ca la CPPA: în IRIS Customer Search verifici fiecare BP din ticket să nu fie prezent — caută și cu 0/00/000 în față → No rows.
IRIS Customer Search → după email/BP (cu 0/00/000 în față) → No rows.CRM Identify Customer → căutare după email → Result List : 0 Accounts Found.BI Team Search: Customers → criteriu E-Mail → Result List gol (0 rezultate).
⚠️ BP de tip GROUP — tratament special: unele BP-uri sunt de tip group („GROUP CUSTOMER"). Arată și se comportă diferit:
View diferit: profilul e GROUP CUSTOMER — Account Details fără Communication Table. Telefonul se adaugă în secțiunea separată Address Independent Communication Numbers (nu în tabelul obișnuit).
Poate să NU se mascheze ca un BP normal, iar în Snowflake rezultatul (Q2) poate fi diferit — poate rămâne cu E01/D01 etc. Nu-l forța la remask la nesfârșit.
BI Team — un BP group apare ca GROUP CUSTOMER (ex. 228162176, DONOTUPDATE).Profil GROUP CUSTOMER — layout diferit; Cust Cleanse Status = Cleansed, fără Communication Table.Telefonul stă în Address Independent Communication Numbers (aici „No result found").
Mesaj de close — EDW pentru BP-uri GROUP (paragraf adăugat)
Those BPs: <group_bp1>, <group_bp2> were masked and cleansed in CRM.
There is no flow of updates to flow from CRM to EDW for these kinds of business partners
Validare BI Team la group: la aceste BP-uri telefonul 000000000 poate să dispară din view — e OK. Principalul e ca BP-ul să fie curat în query (Q2/Q3), nu neapărat să aibă telefonul mascat vizibil în BI Team.
Q2
Per BP — verifici comunicările viitoare (end_date > azi). Rulezi pentru fiecare BP.
Q2 — validate BP
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE SAP_BP_ID = '8006008501'
AND CUST_COMM_CHAN_END_DATE > CURRENT_DATE
Regula Q2: BP-ul e VALID dacă (a) 0 rânduri, SAU (b) toate rândurile au METHOD ∈ {P01,P02,P03} cu telefon mascat (gol / 0000000000). Orice E01 (email), telefon real, sau alt cod activ = INVALID.
✅ VALID · exemplul 2 — doar P01/P02/P03 cu telefon mascat
SAP_BP_ID
METHOD
PHONE_NO
END_DATE
8006008501
P01
0000000000
9999-12-31
8006008501
P02
0000000000
9999-12-31
8006008501
P03
0000000000
9999-12-31
Toate P01/P02/P03 + telefon 0000000000 → mascat corect.
🔴 INVALID · exemplul 1 — email E01 încă activ
SAP_BP_ID
METHOD
EMAIL_ADDR
END_DATE
8006008501
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
Emailul (E01) e încă activ → mascarea n-a prins / BP resuscitat → remask + investigare.
🔴 INVALID · exemplul 2 — telefon real
SAP_BP_ID
METHOD
PHONE_NO
END_DATE
8006008501
P01
5551234567
9999-12-31
METHOD e P01, dar telefonul e real (nu 0000000000) → încă e contactabil → remask.
Q3
La nivel de email — emailul nu mai apare cu E01 activ pe niciun BP.
Q3 — email clean
SELECT *
FROM MKT_DB.EDW.CUSTOMER_COMMUNICATION_CHANNEL
WHERE CUST_COMM_CHAN_METHOD = 'E01'
AND UPPER(CUST_COMM_CHAN_EMAIL_ADDR) = UPPER('john.doe@example.com')
AND CUST_COMM_CHAN_END_DATE > CURRENT_DATE
✅ CURAT — 0 rânduri
SAP_BP_ID
METHOD
EMAIL_ADDR
END_DATE
(niciun rând)
Emailul nu mai apare activ nicăieri → curat, scopul atins.
🔴 NECURAT — leftover (emailul încă activ pe un BP)
SAP_BP_ID
METHOD
EMAIL_ADDR
END_DATE
8006873009
E01
JOHN.DOE@EXAMPLE.COM
9999-12-31
≥1 rând = BP-urile din rezultat (ex. 8006873009) încă au emailul activ (leftover) → acele BP se remaschează.
Dacă la validare găsești ceva NEMASCAT: remaschezi BP-ul (vezi pas 2) și lași în ticket comentariul de mai jos; apoi aștepți 48–72h și reiei validarea.
Comentariu la re-mask (Data processed again)
Data processed again for: <bp1>, <bp2>.
Waiting 48-72Hrs for data to process and proceed with validation
Reziduu: dacă Q2 rămâne INVALID deși mascarea a reușit (BP apare mascat în BI Team, dar Q2 tot blocat), repeți mascarea și investighezi — e cazul în care pipeline-ul resuscită un email vechi pe BP. Dacă BP-ul nu apare deloc în BI search și Q2 e valid → skip (reziduu istoric).
Când BP-urile sunt mascate și verificarea (Q2/Q3) e curată, postezi mesajul de close și închizi ticketul EDW.
Mesaj la close — EDW (validat)
Data validated for: <bp1>, <bp2>
Mesaj la close — EDW cu BP-uri de tip GROUP
Data validated for: <bp1>, <bp2>
Those BPs: <group_bp1>, <group_bp2> were masked and cleansed in CRM.
There is no flow of updates to flow from CRM to EDW for these kinds of business partners
Dacă ai BP-uri de tip group (fără flux CRM→EDW), adaugi al doilea paragraf cu acele BP-uri.
Mesaj la close — EDW, BP negăsit în BI Team (nu se poate masca / reziduu, Q2 invalid)
Data validated for: <bp1>, <bp2>
BP <bp> is not searchable in the BI Team / CRM — there is no record to mask (historical residue).
There is no flow of updates from CRM to EDW for this business partner, so the remaining data cannot be re-identified as this customer.
Când: un BP are Q2 invalid dar în BI Team nu se găsește (inexistent / deja curat = reziduu istoric) → nu-l poți masca. În soft = „accept reziduu EDW" (sare Q2/Q3, IRIS rămâne impus). Adaugi al doilea paragraf cu acel BP, înlocuind <bp> cu numărul lui.
Epsilon = scoaterea clientului din baza Epsilon (Campaign database / loyalty). Verifici emailul în Epsilon → iei profile_id → îl trimiți la ștergere printr-un Loyalty delete request → lași comentariul în ticket → confirmi ștergerea. 🔗 Deschide coada Epsilon în ServiceNow — ticketele „…completely removed from Campaign database".
Termen (SLA) — 45 de zile: ticketul Epsilon împarte același termen cu CPPA și EDW ale aceluiași email: data deschiderii CPPA + 45 de zile calendaristice (nu de la deschiderea Epsilon). ≤14 zile = atenție, ≤5 zile = urgent, sub 0 = depășit.
Rulezi query-ul care caută emailul în Epsilon (PROFILE_EXTRACT) → profile_id-urile.
Epsilon — profile după email
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
Exemplu rezultat
PROFILE_ID
CARD_NUMBER
FIRST_NAME
LAST_NAME
EMAIL_ADDR
ENROLLMENT_STATUS
11111111-2222-3333-4444-555555555555
7700000000000001
JOHN
DOE
john.doe@example.com
A
Ce înseamnă:PROFILE_ID = ce trimiți la ștergere. ENROLLMENT_STATUS: A=activ, I=inactiv, D=șters. 0 rânduri = emailul nu mai e în Epsilon → scopul atins (ticketul se închide, fără pid).
Alternativ
Poți lua profile_id și direct din Epsilon admin: deschizi profilul clientului, iar în URL, după profileId=, e chiar profile_id-ul.
Epsilon admin: deschizi profilul → în URL, după profileId=, e profile_id-ul.
Te loghezi pe support.epsilon.com — introduci emailul tău → Login.
Introduci emailul → Login.
Sus, alegi Request Something.
Meniu sus → Request Something.
Din Product Catalog alegi Loyalty.
Product Catalog → Loyalty.
Alegi Loyalty General Request.
Popular requests → Loyalty General Request.
Completezi forma și dai Submit:
Urgency:3 - Medium
Title:CCPA Requests : Time sensitive
Description: „Please remove the following profiles from the Epsilon database:" + profile_id-urile (unul pe rând).
Description (în formă)
Please remove the following profiles from the Epsilon database:
<profile_id_1>
<profile_id_2>
Formă: Urgency 3-Medium, Title „CCPA Requests : Time sensitive", Description cu profile_id-uri → Submit.
Ce vezi
După Submit primești un număr de caz CS… (CS number).
Se trimite în BATCH: de obicei nu trimiți la fiecare ticket separat — aduni ticketele eligibile care au profile_id și trimiți un singur request pe toate, când ai o cantitate (ex. ~15) sau după un interval (ex. ~10 zile) / când se apropie SLA-ul.
Pui în fiecare ticket (al profile_id-urilor din request) comentariul cu CS-ul:
Comentariu Loyalty delete (Epsilon)
Loyalty deletion request <CS> created for removal of profile_id <pid1>, <pid2> from the Epsilon database.
5 Loyalty „victim" / +pid
Ce faci
Profile-urile de tip victim (de la CPPA — survivor/victim, pas 4) le incluzi aici: loyalty-ul victim salvat se trimite și el la ștergere ca +pid, chiar dacă nu putea fi editat. (De-aia la CPPA salvezi ambele loyalty id separat.)
Re-rulezi query-ul de la pas 2. Șters = enrollment_status = D (Deleted) + email gol, sau 0 rânduri. (Ștergerea nu e instant — job Epsilon.)
Ce vezi
Confirmi că în Epsilon nu mai există rezultat nici după email, nici după loyalty (card number / profile): căutarea întoarce 0 rezultate (sau status D). Atunci clientul e scos din Epsilon.
Query de verificare (Snowflake) — același ca la pas 2
SELECT profile_id, card_number, first_name, last_name, email_addr, enrollment_status
FROM MKT_DB.STG_EPSILON.PROFILE_EXTRACT
WHERE LOWER(TRIM(email_addr)) = 'john.doe@example.com'
✅ VALID — exemplul 1: 0 rânduri
PROFILE_ID
CARD_NUMBER
EMAIL_ADDR
ENROLLMENT_STATUS
(niciun rând)
Emailul nu mai apare în Epsilon → șters.
✅ VALID — exemplul 2: status D (șters)
PROFILE_ID
CARD_NUMBER
EMAIL_ADDR
ENROLLMENT_STATUS
11111111-2222-3333-4444-555555555555
7700000000000001
(gol)
D
ENROLLMENT_STATUS = D (Deleted) + email gol → șters.
🔴 ÎNCĂ NEVALID: status A, email prezent
PROFILE_ID
CARD_NUMBER
EMAIL_ADDR
ENROLLMENT_STATUS
11111111-2222-3333-4444-555555555555
7700000000000001
john.doe@example.com
A
Încă activ cu email → ștergerea nu a fost procesată încă (job Epsilon); mai aștepți / verifici CS-ul.
Alternativ
Poți verifica și în Epsilon admin: Search By Profile → pui emailul (sau card number) → Search → tabelul e gol (0 items).
7 Confirmă în Loyalty General Request (support Epsilon)
Unde
Epsilon support → ticketul Loyalty General Request creat la pasul 3 (CS-ul, ex. CS0709578)
Ce faci
După ce ai confirmat la pasul 6 că profile_id-urile nu mai apar în Epsilon (0 rezultate / status D), intri în ticketul Loyalty General Request și confirmi acolo că au dispărut din Epsilon.
Ce vezi
Support-ul Loyalty (ex. David Daniel) scrie: „The CCPA request has been completed, please verify and let us know." → asta e semnalul să verifici și să confirmi.
Răspuns în ticket — Additional comments → Send
validated
Când: doar după ce tu ai verificat în Epsilon (pasul 6) că profilurile chiar s-au șters. Scrii validated în Type your message here… → Send. Abia apoi închizi ticketul ServiceNow (pasul 8).
Loyalty General Request: support scrie „CCPA request has been completed, please verify…" → tu răspunzi validated (după ce ai confirmat ștergerea în Epsilon).
Ticketele fără profile_id (emailul nu-i în Epsilon) → se închid (nimic de trimis). Cele cu request trimis → se închid după confirmarea ștergerii.
Comentariu la close — Epsilon (emailul nu mai e în Epsilon)
The email <email> is not searchable in epsilon.
Când: emailul nu mai întoarce rezultat în Epsilon (0 rânduri / status D la pasul 6). Înlocuiești <email> cu emailul din ticket.
🆕 Ce e nou — actualizările handbook-ului, cea mai recentă sus. Dă click pe un punct ca să sari direct la secțiunea modificată (se evidențiază câteva secunde).
v1.0
13.11.2026 — prima versiune cu numerotare + changelog
Validare IRIS — 3 scenarii când BP-ul încă apare în IRIS (cont al userului / divergențe+inactiv / altă persoană activă → unmerge Zeta). → CPPA · Validare (pas 7)
Pre-check ServiceNow la începutul CPPA: cauți emailul în SN, verifici dacă nu e vreun unmerge înainte de procesare. → CPPA · Caută clientul (pas 2)
Unlock BP — pași compleți U.1–U.7 cu screenshoturi (SM12 → BUT000 → Delete lock) + nota „închide tab-ul BP din CRM înainte". → EDW · Unlock BP
Mesaj de close pentru reziduu — BP negăsit în BI Team / nu se poate masca (Q2 invalid). → EDW · Închide ticketul (pas 4)
Epsilon — confirmare în Loyalty General Request: după ce verifici ștergerea, răspunzi „validated" în ticketul de support. → Epsilon · Loyalty General Request (pas 7)
CCPA + GDPR Delete Toolkit — screenshoturi reale de upload + nota „Fetch Stats pe interval de date". → CPPA · CCPA+GDPR (pas 6)