Question
Red Alpha, LLC
US
Last activity: 1 Nov 2022 11:34 EDT
Parsing standard formatted email for case type property mapping
I know that Pega can do NLP/entity extraction based on trained models, etc. But I'm looking for info on what is the Pega preferred solution/method for parsing and mapping content from a standard formatted email body into specific case type properties. What is the recommended way to implement this?
For example, I could have an email body that looks like the following:
----------------
REQUEST
Submitter Name: John Doe
Submitter Email: Proprietary information hidden
Submitter Phone: 323-555-1212
ORGANIZATION
Org Name: Acme Corporation
Org Address: 123 Acme Lane, Pittsburgh PA 90210
Org Type: Public
Org Employees: 450
--------------
I'm looking to map these to properties in my case type such as:
.requester.firstName
.requester.lastName
.requester.email
.requester.phone
.org.name
.org.address.streetName
.org.address.city
.org.address.state
.org.address.postcode
.org.orgType
.org.numEmployees
Just an example, but as this email is ALWAYS in a standard format, what's the recommended method for parsing to map into case type properties from within the Email Channel? Thanks in advance
Pegasystems Inc.
IN
@JonathanB9941 Hi Jonathan,
Can you please confirm if you are using email channel from channels and interfaces?
If yes then you can use entity extraction from the behaviour tab where you could provide entities from email and map it to properties. Can you please check this and let us know if it helps?
Red Alpha, LLC
US
@SrinidhiM Thank you for the response. Yes, using Email Channel from Channels & Interfaces as you describe. One part of my issue is the Entities available in the Entity extraction tab as you show aren't all of my case type properties. Instead it is only a smaller set of them (appear to only be scalar properties, as @VikasRaidhan describes below). So part of my question was about getting access to the non-scalar properties, but also curious if there was a "Corporate Pega" recommended approach for direct mapping of formatted emails to specific properties in the case type.
In this use case, I do not have access to or control the originator of the web form that generates the email, but the body of the email is always the same structure. So I was looking for what's the Pega recommended way to make these mappings. I feel like it should be something very straightforward as a one-to-one mapping and not necessarily need ML involvement or any model training as that seems as if it has less rigor.
Pegasystems Inc.
IN
@JonathanB9941 I'd recommend using Machine learning based entity extraction models to parse this kind of data. Preferred way would be to have single Entity rule and all these 'standard' entities embedded within that one entity rule. That will ensure you don't get same text detected with multiple entities. You'll have to provide ample training data as well before the model could start working as expected. I'm thinking around 20-30 training records but could be more. An example of embedded entity rule is pySystemEntities and pyNER which are shipped with Pega platform. https://docs.pega.com/bundle/platform-88/page/platform/decision-management/build-machine-learning-entity-models.html
To your second point of automatically mapping properties. Won't be possible with OOTB entity-property mapping because it's applicable only for scalar properties. In 8.8, we have provided facility to map to one-level deep embedded property. https://docs.pega.com/bundle/platform-88/page/platform/conversational-channels/setting-entity-property-mapping.html
One way to map these entities would be to access detected entities in pyDefault data transform of your case type.
Red Alpha, LLC
US
@VikasRaidhan Thank you very much for your reply. I will investigate the rules you mention and I appreciate your confirmation about the scalar property mapping which is what I had initially found, but wasn't sure if there was another approach.
I was hoping there would be a method that is more rigorous and less ML/model training based for reasons mentioned in my above reply to Srinidhi