WIP
Diference between original and replicate user
Cenário:
...
| Table of Contents |
|---|
SOLUTION
| Info |
|---|
The suggested solution is to change the status for the “replicated” users as “SUBSCRIBED”, while we maintain the real users that accepted the opt-in as “OPTED IN”. |
| Note |
|---|
It’s important to analyze the migrated data from Salesforce in which state the user is mapped. In case of “SUBSCRIBED”, we suggest to move into a deeper analysis of those profiles that could be mapped by the granularity of the data available (ex: loyaltyID) |
ANALYSIS
Register the user by first time in PLK and replicate to BK
I created the user felipepg+braze45@ciandt.com em on PLK STG
Segue os prints de depois de criado
Primeira diferença é no original tem muito mais informações e o nome esta igual ao escrito no campo nome, na replica esse campo pega o conteúdo do email antes do @.
...
Ainda na mesma tela temos alguma diferenças na parte inferior da tela
...
Na segunda aba temos mais algumas divergências:
...
Na terceira aba tbm temos divergências:
O original recebeu varias mensagens
...
=========================
=========================
Agora como ele fica após criar com o mesmo email um cadastro no BK.
Original do cadastro de BK
Nesse caso ambos ficam com o nome correto no topo e o custom attributes tem no original e na replica.
...
A parte inferior da mesma tela
...
A segunda aba
Ele tem praticamente os mesmo dados, acredito q o plk puxa as informações do registro original q ele já tinha
...
E na terceira aba, tbm acredito q ele puxa algumas infos do castrado q já existia no plk.
=========================
=========================
Agora vamos analisar como ficaram os registros anteriores, feito no primeiro cadastro de PLK e com sua replica de BK
Primeira aba na houve mudanças
...
Parte inferior
Segunda aba
The first difference is that original there are many more information, and the name it is the same that the wrote in the field name, in the replicate it gets the first part of e-mail user.
...
In the same page, there are some differences in the inferior part.
...
On the second tab, there are more differences
...
On the third tab, there are more differences:
...
Register the user on BK after has the replication
Now, how it after create with the same email a register on BK
Register original of BK
In this case, both items stay with the same name in top of page, and some other attributes.
...
In the second tab it has the same data, maybe the item get the information of old register.
...
Analyze the first items of first register again
Now we will analyze how stay the old register, made the first register on PLK and with your replicate on BK
Don’t have difference
...
Second Tab:
...
Code
A suggest is to change the code of this file intl-user-service/scripts/utils/utils-users.ts in the getCommPrefsValue function.
This function captures the status of the email or push (unsubscribe, subscribed or opted in).
A possible solution is when the record is a replica and the email is equal to "opted in" we change it to “subscribed”, and to know if the record is a replica we can validate the "loyaltId" record when it is a replica this value is null.
So if the “loyaltId” is null and the email status is "opted in" we change its status to "subscribed"