Case scenario - a case is created from an email—and on the initial screen we want to extract information from the email body and populate certain properties, what would be the recommended approach to achieve this.
Any guidance or suggestions would be greatly appreciated, as this is my first time working with this scenario.
Thanks for raising this scenario — it’s a very common first step when teams start working with email‑driven cases, and getting the placement right early makes a big difference.
My recommended approach in Pega is to keep this as governed case processing, not free‑form agent behavior:
1. Create the case from the email using standard email‑to‑case
Use Pega’s email channel / email instantiation to create the case when the email arrives. This ensures the email body is captured as part of the case context and remains fully auditable. No AI decisions should be made at this point.
2. Extract data using GenAI Connect in the Create stage (or an early explicit step)
Once the case exists, use a GenAI Connect rule to extract information from the email body and populate specific case properties. This is the safest and most predictable pattern because:
Inputs are explicit (email body, subject, metadata)
Outputs are structured and mapped directly to known case fields
The behavior is bounded, testable, and observable
3. Keep AI out of case control logic (unless you have high accuracy/performance)
GenAI should extract and propose values, but workflow, rules, or humans should decide what happens next. Avoid letting AI advance stages, route the case, or auto‑submit based solely on extracted content.
4. Add human review where correctness matters
If the extracted data affects compliance, downstream automation, or customer communication, route the case to a review assignment before proceeding. This is a recommended pattern when working with unstructured input like emails.
5. When to use an Agent (and when not to)
For a first implementation like this, GenAI Connect is preferred. Agents are better suited for multi‑step reasoning or conversational scenarios and introduce more autonomy than is usually needed for simple extraction.
This pattern keeps AI inside clear workflow boundaries, preserves auditability, and scales safely as volume increases.
Curious to hear from others:
Do you place extraction directly in the Create stage or as a separate early step?
Where have you found human review to be essential versus optional?
I was trying to follow the same approach. Few challenges.
We are currently using Email Triage OOTB activity to create case(but is not needed) do you suggest any other OOTB activity to only create the case in constellation?
While creating the GEN AI Connect rule I see we can only give Fields of type attachment as the target please see below image and thats the reason I can specify the model to read the property that holds the value of the email body.
May be I ma missing something any advice will be of great help
Hi @RUDRADEEPS ,
Please read through the below links on Creating Gen AI connect rule and configure accordingly.
@RUDRADEEPS I think the challenge here is that you are mixing two different Pega patterns: Email Bot / email triage entity extraction and GenAI Connect attachment analysis.
For the specific requirement of reading the email body and populating case properties when the case is created from an email, the more natural OOTB pattern is usually Email Bot / email channel entity mapping, not GenAI Connect reading a body property as if it were an attachment.
If the input is the email body itself, I would not start with GenAI Connect. I would first use the standard email-to-case / Email Bot flow and configure entity extraction + mapping in the email channel so the values are identified from the email content and mapped directly to case properties during creation.
If you are currently using the Email Triage OOTB activity just to create the case, that may still be fine if your implementation uses the standard email channel. The key point is that for create case from inbound email and extract values from the body, Pega’s email channel / Email Bot path is already designed for that. I would not replace it with GenAI Connect unless the extraction is too complex for standard entity extraction.
Your observation about GenAI Connect is valid. Yo analyse attachments in GenAI Connectors, you first need an attachment field to store the attachment and add the field to a view. That’s why you are seeing an attachment-oriented target.
Use GenAI Connect only when you need richer extraction beyond what Email Bot entity mapping can do. Even then, I would run it as an early case step after creation, using the body text as explicit prompt input rather than trying to force the attachment flow to read the body property.
