Overview
This page illustrates what you can expect when the field synchronization has been configured on a mapping.
Notice that not all fields defined on your Jira instances are available for synchronization.
Following you can find the list of field that can be synchronized and the admissible combinations of synchronizations for different field types.
Furthermore, notice that the syncing behavior can differ with respect to the type of field in sync.
E.g. Case of Component, the synchronization is performed on adding a new component same way then deleting a component. Case of Attachment, the synchronization is performed on adding a new attachment exclusively.
In particular, you can expect a different behavior with respect to the following groups of fields:
Comment
Attachment
Summary and Description
Component, Affect Version and Fix Version
Priority, Assignee and Reporter
Custom Fields.
Consider that the synchronization is active on issue creation, editing and linking.
Additionally, the Sync on create option allows chosing:
if the create screen opened via the via Herzum Quick actions button must be pre-populated (Sync on create = True) when creating an issue via the Herzum Quick actions button
if the issue created via the Escalate issue post function must be populated based on the value on the source issue.
While on issue editing the sync type both is naturally provisioning, on issue creation and/or linking the app behavior follows some established conventions that are going to be detailed for:
issue creation and/or linking via Herzum Quick actions
issue creation and linking via Escalate Issue post function.
At last, notice that, in general, you can expect the same behavior for a Local Partnerships as for a Remote Partnership.
This guide explain in detail all mentioned topics so that you can configure suitable fields mappings.
Fields availability and Fields mapping around different field’s type
Fields availability
The set of Jira fields available for a syncing on a Fields mapping configuration include:
Affected version
Assignee
Attachments
Comment
Component
Description
Due Date
Fix version
Priority
Reporter
Summary
Custom fields available for a field syncing configuration are:
Text Field (single and multi line)
Number field
third party custom fields (e.g. the Tempo "Customer Account" custom field) recognized to be text type
Select List (single and multiple choice) -  (for Local Partnership exclusively)
Radio Buttons -  (for Local Partnership exclusively)
Checkboxes -  (for Local Partnership exclusively)
Select List (cascading) -  (for Local Partnership exclusively)
User and Group Picker.
Data Picker
Data Time Picker
Fields mapping around different field types
Exception made for the following fields, you are able to create a field mappings between the same JIRA field types.
Summary Description
Priority
Summary, Description, Text field
Affect Versions Fix Versions
Text Field (single line)
Text Field (multi line)
Select List (single choice)
Radio Buttons
Select List (multiple choices)
Check-boxes
Custom fields (Text Field)
Priority
Summary, Description
Text Field (single line),Text Field (multi line)
Allowable fields for Sync on create
The sync on create parameter set to True allows to:
populate the issue create screen opened on Herzum quick action button
populate an issue created via the escalate issue post function.
The mentioned setting is available for mostly of the listed fields available for a field mapping.
This option is not available for Comments, Attachment Assignee and Reporter.
Attachment’s Syncing behavior
As first you must be aware that attachment synchronization is based on the attachment file name. So, two files having the same name are considered to be the same.
As consequence of it, an attachment is synced only if a file having the same name doesn't exit already on the target issue.
Notice that sync behavior is the same for Partnerships configured across the same or different source and destination Url/s.
Consider that syncing of attachment deletion is not supported yet.
Depending by the configured sync versus you can expect the syncing behavior described below.
Syncing is Both
On adding one or more attachments, they are synced on all the linked issue/s and, if other synchronizations have been configured on the target issue/s, they are propagated again indefinitely.
On issue creation/linking or only linking an existing one via the Quick actions buttons, all attachments are synced in both directions and, if other synchronizations have been configured on the source and/or on the target issue/s, they are propagated again indefinitely.
On issue creation and linking via the Escalate issue post function, all attachments on the source issue are synced on the created/linked issues, for Mappings associated to Local Partnership exclusively (this feature isn't available for Remote Partnership yet).
Syncing is source versus target
On adding one or more attachments on the source issue, they are synced on all the linked issue/s and, if other synchronizations have been configured on the target issue/s, they are propagated again indefinitely.
On issue creation via the Quick actions buttons, all attachments on the source issue are synced on the created/linked issues.
On issue linking via the Quick actions buttons,  attachments are synced on all the linked issue and, if other synchronizations have been configured on the target issue, they are propagated again indefinitely.
On issue creation and linking via the Escalate issue post function,  all attachments on the source issue are synced on the created/linked issues, for Mappings associated to Local Partnership exclusively (this feature isn't available for Remote Partnership yet).
Syncing is target versus source
On adding one or more attachments on the target issue, they are synced on all the linked issue/s and, if other synchronizations have been configured on the source issue/s, they are propagated again indefinitely.
On issue creation/linking via the Quick actions buttons attachments on the source issue are Not synced on the created issues.
On issue exclusively linking via the Quick actions buttons,  attachments on the target issue are synced on all the source issue and, if other synchronizations have been configured on the source issue, they are propagated again indefinitely.
Comment’s Syncing behavior
Main difference between Comments syncing and other field syncing consists of it is performed at one linking’s level.
Apart the mentioned limit, it follows the same behavior described for all other fields in case of Issue creation and/or linking via quick actions buttons or escalate issue post function automatic creation.
Consider that, differently by attachment syncing behavior, the syncing on attachment deletion is supported in addition to add and edit comment syncing.
Notice that the comments added by the user, that are candidates to be synced, are managed by the app, so that they can be associated to the synced comment created by the system, by following the following convention:
a comment added by the user includes the following header: Comment synced by HQL (id:<Issue id>)
a comment added by the system includes the following header: Comment synced by HQL (<Partnership Id>: <Issue id>)
Notice that sync behavior is the same for Partnerships configured across the same or different source and destination Url/s.
Depending by the configured sync versus you can expect the syncing behavior described below.
Syncing is Both
On adding a comment, it's synced on all the linked issue/s.
On editing a comment:
if it is has been created by the system, it’s synced only on the source issue.
if it has been created by by the user, each issue having a comment synced with it is processed and the comment updated.
On deleting a comment:
if it is has been created by the system, the source comment is deleted and each issue having a comment synced with it is processed and the comment deleted
if it has been created by by the user, each issue having a comment synced with it is processed and the comment deleted.
On issue creation and linking via the Quick actions buttons all and only the comments added by the user on the source issue are synced on the created/linked issue.
On issue linking via the Quick actions buttons:
all and only the comments added by the user on the source issue are synced on the linked issue
all and only the comments added by the user on the linked issue are synced on the source issue.
Syncing is source versus target
On adding a comment on the source issue, it's synced on all the linked issue/s.
On editing a comment:
on the target issue it’s NOT synced on the source issue.
if it has been created on the source issue by the user, each issue having a comment synced with it is processed and the comment updated.
On deleting a comment:
on the target issue, the source comment is NOT deleted
if it has been created on the source issue by the user, each issue having a comment synced with it is processed and the comment deleted.
On issue creation and linking via the Quick actions buttons, all and only the comments added by the user on the source issue are synced on the created/linked issue.
On issue linking via the Quick actions buttons all and only the comments added by the user on the source issue are synced on the linked issue.
Syncing is target versus source
On adding a comment on the target issue, it's synced on all the source issue/s.
On editing a comment:
on the source issue it’s NOT synced on the target issue.
if it has been created on the target issue by the user, each linked issue having a comment synced with it is processed and the comment updated.
On deleting a comment:
on the source issue, the comment on the target issue is NOT deleted
if it has been created on the target issue by the user, each linked issue having a comment synced with it is processed and the comment deleted.
On issue linking via the Quick actions buttons, all and only the comments added by the user on the linked issue are synced on the source issue.
Summary, Description, Assignee, Reporter and Due Date
Sync behavior for the fields Summary, Description, Assignee, Reporter and Due Date is the same for Partnerships configured across the same or different source and destination Url/s.
Depending by the configured sync versus you can expect the syncing behavior described below.
Syncing is Both
On issue creation via the Quick actions buttons, data are synced from the created issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.
On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.
On linking an existing issue, data are synced from the linked issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.
Syncing is source versus target
On issue creation via the Quick actions buttons, data are synced from the source issue to the created issue.
On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.
On linking an existing issue, data are synced from the source issue to the created issue and, if other synchronizations have been configured on the linked issue, syncing is propagated again indefinitely.
Syncing is target versus source
On issue creation via the Quick actions buttons, data are synced from the created issue to the source issue.
On issue creation via the Escalate issue post function, data are not synced.
On linking an existing issue, data are synced from the linked issue to the source issue and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.
Component, Affect Version and Fix Version syncing behavior
Sync behavior for the fields Component, Affect Version, Fix Version is basically the same behavior described for Summary, Description and Custom fields.
In addition, cause of each of them can be associated to one, null or a list of values, you can expect the synchronization on adding and deleting a value from the list by following same behavior already described.
The major aspect differs those specific fields from the other type of synchronization is that sync can fail due to different Versions and Components settings across different projects and/or Jira instance.
When sync fails due to the mentioned scenario, Comments are logged to alert the user for syncing failure. See General troubleshooting guidelines for further information on this topic.
Notice that when sync fails as default the app set to Null the value of the target field. An exception is made for field configured to be required where the existing value is retained.
Priority, Assignee and Reporter syncing behavior
Sync behavior for the fields Priority, Assignee and Reporter is basically the same behavior described for Component, Affect Version and Fix Version, including the behavior on sync failure but
as per Summary, Description and Custom fields behavior they can assume only one value.
Fields Assignee and Reporter cannot be configured on a field mapping to have Sync on Create = True and it implies the following limitations:
on issue creation and linking via the Quick actions buttons the issue create screen will not be populated by having the values of the source issue
on issue creation via the Escalate issue post function the issue will not be populated by having the values of the source issue.
Custom fields
Sync behavior for Text Field (single and multi line), User and Group Picker, Number Field and Date Picker is the same case of Local Partnership (same source and destination Url) or Remote Partnership (different source and destination Url/s).
The Select list, Radio button and Checkboxes can be synced only toward a Local Partnership.
Depending by the configured sync versus you can expect the syncing behavior described below.
Sync versus is Both
On issue creation via the Quick actions buttons, data are synced from the created issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.
On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.
On linking an existing issue, data are synced from the linked issues to the source and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.
Sync versus is source versus target
On issue creation via the Quick actions buttons, data are synced from the source issue to the created issue.
On issue creation via the Escalate issue post function, data are synced from the source issue to the target when Sync on create is set to true, syncing is not active on issue creation if Sync on create is set to false.
On linking an existing issue, data are synced from the source issue to the created issue and, if other synchronizations have been configured on the linked issue, syncing is propagated again indefinitely.
Sync versus is target versus source
On issue creation via the Quick actions buttons, data are synced from the created issue to the source issue.
On issue creation via the Escalate issue post function, data are not synced.
On linking an existing issue, data are synced from the linked issue to the source issue and, if other synchronizations have been configured on the source issue, syncing is propagated again indefinitely.

In order to allow synchronization working as expected, the field configuration of the target project must include the custom field.
Furthermore, the Select List, Radio Buttons and Check-boxes Options must be consistent across the synced source and target fields.
If the selected options cannot be synced on the target issue, an alert  is logged on the source and on the target issues comments.
Issue History updates due to synchronization
Updates on issue’s data caused by a synchronization performed by Herzum Quick Linker are retained same way of updates applied by an user.
Notice that the applied updates are attributed to the user configured on the partnership as source/destination credential:
synchronizations applied on the source issue are retained as made by the user configured on partnership source credentials
synchronizations applied on the target issue are retained as made by the user configured on partnership destination credentials.

Browser not supported