I am now using a data model to support my marketing campaigns (using other tool) and I’m trying to understand if I can reproduce my model in Pega.
I have 6 entities through which I can make contacts: Client, Account, Service, E-mail, Lead and Prospect. The first three include different information but they have a connection between them and we can consider that they represent 3 levels. The Client table only have the customer basic information, the Account table only have the account information, but is connected to the first one through the CustomerID, and the Service table only have service related information, and is connected to the Account table through the AccountID. The other 3 entities (E-mail, Lead and Prospect) are completely independent.
In the Pega context, I understand that I can extend the customer class (which I assume that could be my Client) and associate other entities to it, so I assume that those entities could be my Account and Service. My problem here is that I need to know which one of these entities was the contact target (I mean, for example, if my intent was to contact the service or the client directly, regardless of the contact channel). Is there a simple way to extract this information for reporting purposes?
I also understand that Pega includes the Prospect context, so this wouldn’t be a problem. Although I wasn’t able to understand how could I include my E-mail and Lead entities in the Pega context. Is it possible to add more data mart entities to the Pega Marketing context rather than Customer and Prospect?
Thank you in advance,
***Edited by Moderator Marissa to update platform capability tags***
Yes, I did. It was through that guide that I learned how to extend the customer class and to associate other entities to it, like my Account and Service entities. Although I couldn't find a way to introduce my E-mail and Lead entities in the Pega context. Do you have any advice?
In order to better help, I think we need a little more information:
What version of the product are you looking at?
With respect to the first 3 entities
are they 1-1 relationships or 1-N relationships? i.e., can a contact have 1 account or many accounts. Can accounts have 1 or many services?
When you market to or communicate, who is that done with. I assume the contact entity (the actual person, right?).
In Pega Marketing version 7.4, we have introduced a the ability to market at different Context levels. The entity you will physically communicate with is considered the primary context. If you intend to communicate in the context of account or services (but still through the context of the 'person' behind these), then you should model account and service as additional contexts.
What is the purpose of the Lead and Email entities? They both sound like prospect records of some kind, but I can't tell. If so, would it make sense for the prospect record to include an attribute that defines the record type as prospect, lead or email? To somewhat answer your question, there is no current ability to define more tope level entities and have them be entities that are considered entities you market/communicate with.
They have 1-N relationships, meaning that a client can have more that one account and an account can have more than one service;
When I’m marketing, I need to know if the contact is intended to be to the client (Contact via address), the account (contact via billing invoice) or the service (contact phone number), meaning that it is not always the actual person that I have interest on, but the entity;
I believe that that approach to “Context Levels” may solve the problem, as long as I could keep the information about the context level even if the physically communication is considered to be done to the primary context;
The Lead and Email entities have different attributes from the Prospect entity, so I believe that the solution can’t be the inclusion of the Lead and Email information in the Prospect record. In our model, the Prospects are ex-clients, the Leads are other operators’ clients and the Emails are people who revealed interested on receiving our newsletter. Considering this information, can you propose other solution?