A Bonded Attachment is created for every synchronised attachment, storing relevant data.
For every attachment that is sent or received, a Bonded Attachment record is created that links to the attachment. This allows the system to automatically make size calculations and track if the attachment has been sent.
The attachment sits on the bond, but is also linked to and can be viewed from the transaction that sent it.
For implementations using multiple integrations with one record, one attachment can be added and it will automatically be sent and tracked across all the relevant bonds.
Unifi has automated checks that prevent attachments and updates being sent back to the originator (controlled by the Connection).
The following table gives a description of the fields that are visible on the Bonded Attachment record:
The unique Bonded Attachment identifier.
The attachment synchronisation state.
The Bond this record belongs to.
The Transaction this attachment was sent with.
The size in bytes of the attachment.
The attachment content type.
Glide date time
The time the attachment record was created.
The person/system who created the attachment record.
The system attachment.
The file name of the attachment.
Information message about the attachment synchronisation.
The state is set in conjunction with the information contained on the Integration & Bond (concerning permitted file types & attachment sizes etc.) and is used to determine whether or not to send the attachment, or where it sits in the process. The Bonded Attachment lifecycle can be seen in the following table which describes the
Statefield value choices:
The attachment is queued ready for sending.
The attachment is in the process of being sent.
The attachment has been sent successfully.
The attachment has been sent & we have received a receipt acknowledging it.
An attempt was made to send the attachment, but was rejected.
There was a technical reason sending the attachment failed.
The attachment was ignored (E.g. because it exceeded the maximum allowed file size).