# Attachments & Comments Attachments and comments carry critical context in enterprise workflows. A screenshot linked to a bug report, a work note added during triage, or a compliance document attached to a change request - all of these need to follow the ticket as it moves between systems. ZigiOps supports the synchronization of both file attachments and comment threads as part of a standard integration workflow, without requiring custom scripts or additional middleware. This page explains how attachment and comment syncing works in ZigiOps, what types of content can be transferred, how to configure Related Field Mapping for these use cases, and what to watch for in production deployments. ### What is Related Field Mapping in ZigiOps? Attachments and comments are not standalone fields - they are related objects tied to a parent record. ZigiOps handles them through Related Field Mapping, a specialized configuration section available within each Action in a workflow. While the main **Field Map** tab controls which fields are written to the target record (such as summary, priority, or status), the **Related Filters** section controls which related objects are collected from the source and how they are delivered to the target. Related Field Mapping follows the same Extract-Transform-Load logic as standard field mapping but operates on nested or child objects rather than flat record fields. > **Screenshot placeholder:** ZigiOps Action editor showing the Related Filters tab with an attachment sync configuration. > > *Alt text: ZigiOps Action editor showing the Related Filters tab with an attachment sync configuration* > > *Figure: Related Filters tab in a ZigiOps Action - used to configure attachment and comment syncing* ### What Types of Attachments Can ZigiOps Sync? ZigiOps can transfer file attachments between systems at the binary level. The actual file content is read from the source system's API, transmitted through ZigiOps, and written to the target system's API. The following attachment types are commonly synced across enterprise integrations: | Attachment Type | Common Use Case | Notes | | -------------------------------------- | ---------------------------------------- | ------------------------------------------------------------------------------ | | Screenshots and images (PNG, JPG, GIF) | Bug reports, incident documentation | File size limits vary by target system; confirm before deployment | | Log files (TXT, LOG) | Incident triage, root cause analysis | Large log files may need chunking or truncation depending on API limits | | Documents (PDF, DOCX, XLSX) | Change requests, compliance records | Binary transfer preserves file integrity; no content transformation is applied | | Archive files (ZIP) | Batch deliverables, deployment packages | Some systems may restrict archive uploads; verify target API permissions | | Configuration files (XML, JSON, YAML) | DevOps pipelines, infrastructure tickets | Transferred as binary; content is not parsed or transformed by ZigiOps | ZigiOps does not modify file content during transfer. The attachment is read from the source system API response and posted to the target system's attachment endpoint as-is. ### What Types of Comments Can ZigiOps Sync? Comment syncing covers text-based discussion threads and journal entries associated with a parent record. Different systems model comments in different ways, and ZigiOps accounts for these distinctions through explicit mapping configuration. | Comment Type | Systems | Sync Behavior | | ---------------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Public comments (customer-visible) | Jira, ServiceNow, Zendesk, Salesforce | Synced by default when comment sync is enabled | | Work notes (internal only) | ServiceNow, BMC Remedy | Must be explicitly filtered; syncing work notes cross-system may expose internal data | | Journal entries | BMC Remedy, ServiceNow | Treated as internal records; apply the same filtering caution as work notes | | Additional comments | ServiceNow | ServiceNow separates additional comments (external) from work notes (internal); map each type deliberately | | System-generated comments | All systems | Comments created by the integration user; ZigiOps can tag or prefix these to distinguish them from human-authored entries | #### ServiceNow Comment Types: A Critical Distinction ServiceNow separates comment types by audience. **Work Notes** are visible only to agents and internal teams. **Additional Comments** are visible to end users and customers. When syncing from ServiceNow to an external system such as Jira or Azure DevOps, all comments may appear identical in the target. Without a filter condition, internal work notes may be posted as public comments in the target system, creating compliance and confidentiality risks. Best practice is to configure the Related Filter with an explicit condition that restricts sync to Additional Comments only, unless there is a deliberate requirement to sync internal notes to a controlled audience in the target system. ### How Do I Configure Attachment Syncing in ZigiOps? Attachment syncing is configured in the **Related Filters** section of a workflow Action. The steps below describe the general configuration process. Specific field names vary by source system. 1. Open the workflow Action where attachments should be synced. 2. Navigate to the **Related Filters** tab. 3. Add a new Related Filter entry and select the attachment entity from the source system (for example, `sys_attachment` in ServiceNow or `attachments` in Jira). 4. Map the attachment fields to the target system's attachment endpoint. At minimum, map the file name and the binary content field. 5. Apply any required filter conditions (for example, restrict by file size or file type if the target system enforces limits). 6. Save the Action and run a test sync against a record with a known attachment. > **Screenshot placeholder:** ZigiOps Related Filters tab showing an attachment sync configuration with field mappings for file name and content. > > *Alt text: ZigiOps Related Filters tab showing an attachment sync configuration with field mappings for file name and binary content* > > *Figure: Attachment sync configuration in ZigiOps - Related Filters tab showing field mapping for file name and binary content* ### How Do I Configure Comment Syncing in ZigiOps? Comment syncing follows the same Related Filter approach as attachment syncing. The configuration targets the comment or journal object in the source system rather than the attachment object. 1. Open the workflow Action that manages the parent record sync. 2. Navigate to the **Related Filters** tab. 3. Add a Related Filter entry for the comment entity (for example, `comments` in Jira or `journal_field` in ServiceNow). 4. Map the comment body field to the equivalent field in the target system. Optionally map the author and timestamp fields if the target system accepts them. 5. Add a filter condition to restrict comment type where needed (for example, exclude work notes from syncing to external systems). 6. For bi-directional comment sync, configure a matching Related Filter in the reverse-direction Action. Define which comment types flow in each direction to avoid duplication. > **Screenshot placeholder:** ZigiOps Related Filters tab showing a comment sync configuration with a filter condition excluding work notes. > > *Alt text: ZigiOps Related Filters tab showing a comment sync configuration with a filter condition excluding work notes* > > *Figure: Comment sync configuration in ZigiOps - Related Filters tab with a condition filtering out internal work notes* ### Can Comments and Attachments Sync in Both Directions? Yes. ZigiOps supports bi-directional comment and attachment sync. Each direction is configured as a separate Related Filter in the corresponding workflow Action. For a Jira-to-ServiceNow integration, one Action handles the Jira-to-ServiceNow direction, and a second Action (or a reverse workflow) handles ServiceNow-to-Jira. When enabling bi-directional comment sync, apply the following rules to prevent infinite loop scenarios where a comment synced from System A to System B triggers a reverse sync back to System A: * Tag all comments created by the ZigiOps integration user with a recognizable prefix or label. * Add a filter condition in each Related Filter that excludes comments authored by the integration user. * Define explicit ownership rules: specify which system is authoritative for each comment type. * Test the bi-directional flow end-to-end in a staging environment before enabling in production. ### What Are the Common Issues with Attachment and Comment Syncing? | Issue | What Goes Wrong | How to Fix It | | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | Internal comments exposed externally | Work notes synced to public-facing systems create compliance risks | Add an explicit filter condition to exclude internal comment types from cross-system sync | | Attachment size limit exceeded | Target system rejects the attachment because it exceeds the allowed file size | Check the target system's API documentation for size limits; add a filter to exclude oversized files or compress before transfer | | Duplicate comments on re-sync | The same comment is posted multiple times because the Related Filter does not track what has already been synced | Use the `lasttime` field and timestamp-based filtering to collect only new comments since the last polling cycle | | Binary corruption | File content is corrupted during transfer due to incorrect encoding handling | Confirm that ZigiOps is reading and writing the attachment using the binary content field, not a text encoding of the file | | Missing author attribution | Comments appear as authored by the integration user rather than the original author | Map the author field explicitly if the target system supports it; otherwise, prefix the comment body with the original author name | | Salesforce attachment detection gap | Salesforce does not update `lastmodifieddate` when an attachment is added, causing ZigiOps to miss the change | Implement a Salesforce-side trigger that updates `lastmodifieddate` when an attachment record is created | ### Where Can I Go from Here? After configuring attachment and comment syncing, the following topics provide additional depth for building complete integrations: * **Custom Fields Syncing:** Map non-standard fields that exist only in specific system instances * **Filters and Conditions:** Control which records and related objects are collected and under what criteria * **Data Mapping Fundamentals:** Understand the full range of field mapping types available in ZigiOps * **Best Practices:** End-to-end guidance for designing, testing, and maintaining integrations --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.zigiwave.com/design-and-mappings/attachments-and-comments.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.