Mapping Email Listener Attachment to Case Attachment Property (Constellation 25.1)

General
,
1

I’m working on a requirement in Constellation 25.1 where I need to map an attachment received via an email listener to an attachment-type property in my case.

Scenario:

  • When an email is received, a case is automatically created using the email listener.

  • The attachment is successfully added to the case, and we can view it in the case instance (Attachments section).

  • However, we are unable to find the attachment data in the clipboard under pyWorkPage or any accessible page/property.

  • The only reference we can see is a relationship key (pzInsKey) pointing to Data-WorkAttach-File.

What we observed:

  • From tracing, the email listener calls the AddAttachmentFromMail activity.

  • This activity saves the attachment as a Data-WorkAttach-File instance.

  • The actual file content is stored in the pyStream property of that class.

Requirement:

  • We need to map this attachment to a case-level property of type Embed-Attach-File (single page property).

  • However, we couldn’t find a direct way to access or copy the attachment data into this property.

Questions:

  • Is it possible to map an email listener attachment directly to an attachment-type property in the case in Constellation?

  • If yes, what would be the recommended approach?

Any guidance or best practices would be greatly appreciated.

Thanks in advance!

1 Like
2

The attachments will be stored in the repo. Do you have any instance Data-WorkAttach-File created through the Email listener? If yes, can you please check the Repo Name, File name in the xml of that particular instance. Also, please confirm if you’re able to see the attachment in Utility panel

3

Yes, the attachment is being stored in the repository, and a Data-WorkAttach-File instance is getting created through the email listener.

We checked the XML of the instance, and we can see the repository-related details such as the repository name and file name present there.

Also, we are able to view the attachment in the Utility panel under the case, so it is correctly associated with the case.

4

Hello @TharushiK176830171 - Welcome to the community.

It is not recommended to embed email listener attachments as case-level attachment properties. If it serves your purpose the better approach is to access attachments by reference, allowing the platform to continue managing the binary content as Data-WorkAttach-File instances. You may store the attachment’s pzInsKey along with any required metadata (such as file name, type, or size) on the case. This metadata can be populated during post-processing by querying the created Data-WorkAttach-File using the pzInsKey. You may also try to introduce critical information as part of metadata but at the risk of being openly accessible.

This approach avoids duplicating content already stored in the repository, preserves attachment lifecycle consistency, supports variability in attachment structure (assuming your incoming attachments do not follow a fixed template), and prevents long-term upgrade and maintenance risks that arise from embedding binary data on the clipboard.

1 Like
5

Hi @VikasT,

I definitely do agree to your point about avoiding duplication of stored content.

However my understanding was that an attachment case property (Embed-Attach-File) is a reference itself. Would it be an acceptable pattern to have that case prop referencing the same stored content as the Link-Attachment object initially created (and surfaced in Utilities wdget) ?

That’s what I sometimes do for demo needs, but happy to get LSA feedback here to validate (or not :slight_smile: ).

Example below (pre-processing step with Data Transform within business case): Email attachment has been linked to business case and is available from D_AttachmentList (list of Link-Attachment objects, a.k.a links to stored attachments). Key is copied to case field of type attachment (.EvidencePhoto) that is now referencing the stored content as well.

image
image1476×289 36.3 KB

1 Like
6

Hi @VikasT @RameshSangili @VALLC ,

Thanks a lot for the suggestion that approach worked for us. Using D_AttachmentList, we were able to copy the pzInsKey and successfully map the attachment to a case property of type Embed-Attach-File (so now the property references the same stored content without duplication).

Next Requirement
We are trying to pass this attachment to a GenAI connector (DocAI) for analysis (it only accepts attachment-type properties).

However, we are encountering an error when submitting:

Error Code: 400 - The request could not be processed due to invalid input parameters.

image
image1509×890 46.5 KB

From tracer

Gateway Invalid Request: upstream returned status 400
{"message":"1 validation error detected: Value at 'messages.1.member.content.1.member.document.format' failed to satisfy constraint: Member must satisfy enum value set: [docx, csv, html, txt, pdf, md, doc, xlsx, xls]"}

image
image1353×713 36.1 KB

After comparing the XML of

  • Attachment uploaded manually :white_check_mark: (working)
  • Attachment coming from email :cross_mark: (failing)

We noticed a difference in pyAttachMimeType

  • Email attachment
application/pdf; name=promissory.pdf; x-apple-part-url=XXXX
  • Manual upload
application/pdf

It seems the GenAI connector expects a clean MIME type (e.g., application/pdf) and fails due to the additional parameters in the email attachment.

What we tried

  • Attempted to overwrite pyAttachMimeType in the Email Service Activity
  • Tried updating it via an activity by opening the instance and modifying the XML

But in both cases, the value was not getting updated.

Questions

  • What is the correct way to override or sanitize pyAttachMimeType for attachments created via email listener?
  • Is there a recommended approach to make such attachments compatible with GenAI connectors?

Any guidance would be really helpful! Thanks in advance!

7

indeed, the GenAI-Connect rule is checking if the attachment extension is supported by the referenced LLM, and the mime type is not available directly from the Link-Attachment object. I forgot about this one :frowning: .

What you can do – if you know in advance the attachment extension – is to set the .pyFileExtension property of your attachment case field to “pdf” or whatever extension is awaited. It will be enough to make the Connect-GenAI call work.

image
image1043×341 37.8 KB

If extension is not known upfront, you’ll have to fetch it from the Work-Attach-File object.

8

For the dataworkattach instance I have included the two xml files.

  1. P-5022_Manual Attachment XML-Working
  2. P-7001_Email Attachment XML - Not Working

In the working one we have observed

  • pyAttachMimeType is “application/pdf” for the working one (P-5022) and not working one it was "application/pdf; name="Print_My_Enrolments.pdf " (P-7001).
  • pyAttachEncoding (not present) for P-5022 and "application/pdf; name=“Print_My_Enrolments.pdf” for P-7001
  • pyStyle is missing from the P-7001

Not sure this is a reason caused the 400 error with the GenAI, this is an observation only. Also, the two tracer logs have been attached here for your reference.

  1. Tracer for the Email Listener - Admin Studio
  2. Tracer for GenAI Process in the Case - Dev Studio

Since the Dev Studio log exceed 110MB limit I have uploaded it to the one drive, you can access it from there.

Link - Support Request Documents

9

if we pass the file name with extention to this function pxGetMimetypeFromFileName it returns correct mime type