Tracking Changes to Integration Records

If you want to review changes that were made to an integration record, you can refer to the system notes for that record. System notes are used to track events such as the creation of the record, the initial values of its fields, and subsequent updates. For example, if a user changed the State field from Blocked to Enabled, a system note would provide a record of that change.

For each event, the system records details such as the ID of the user who made the change and the timestamp of the change. If a user changed the value of the field, the system note also shows the field’s former value.

For more details, see the following topics:

For general details about working with system notes, see System Notes Overview and Searching System Notes.

Finding System Notes for an Integration Record

You can locate system notes for integration records in either of the following ways:

Special Cases Related to System Notes Logging

System notes for the integration record are similar to system notes for other types of records. However, be aware of special behaviors related to certain fields and situations, as follows:

Logging for the Last State Change Field

The Last State Change field shows the date of the last change to the State field. Changes to this field are reflected in the record’s system notes. However, note the following: If the State field is changed multiple times in one day, only one system note is created to reflect modification to the Last State Change field. The reason is that this field shows only a date, not a time of day.

However, you can track the details — including the times — of all State changes, by the system notes logging for the State and Last State Change By fields: System notes are created to reflect all of each day’s changes to these fields. Each of these system notes includes a date and time.

For example, the following screenshot shows system notes for a record that had its State changed several times on Feb. 5. The log includes only one change to the Last State Change field, but the details of each State change are logged through the other system notes.

System notes showing the last state change of an integration record.

Logging for the State Field

When you create an integration record and save it with its State set to the default of Enabled, the system logs two system notes in regard to this field: One note shows that the field initially had a value of Blocked. Another system note with the same timestamp shows that the field’s value changed to Enabled.

System notes showing the state of an integration record.

By contrast, if an integration record was installed through auto-installation or bundling, only one event is listed for the State field. This note shows that the field was saved with whatever value it had at the time of installation.

System notes showing the state of an integration record installed through bundling.

Logging for the Reset Credentials Button

If you own an integration record that has the Token-based Authentication option selected, you may at times need to reset the consumer key and secret. To regenerate these values, you open the record for editing and click the Reset Credentials button. This action is logged in the system notes as the setting of the Token-Based Authentication Credentials field. The system lists a new value of Reset Credentials.

System notes showing a Reset Credentials action.

The credentials are not displayed in the system notes. Credentials are not displayed anywhere on the record after being shown for the first time.

Generation of an Application ID Is Not logged

When you create a new integration record in your account, an application ID is automatically generated. However, this value is not one of those values listed in the system notes at the time you save the new record. The system notes contain no indication that a value for the field was set.

If you need to locate the application ID, it is visible on the integration record itself and in the integration record list view, but only by authorized users in the account that owns the record. Note that, although application IDs are not considered authentication credentials, you should consider application IDs to be confidential.

Logging for Records Shared by Sandbox and Production Accounts

In some cases, an integration record might exist in both your production and sandbox accounts. For example, you could create a record in your sandbox and install it in your production account. In many such cases, the record is fully editable in both accounts. (For details on when this is possible, see Using Integration Records in Sandbox Accounts.) However, if you make a change in one account and the change is propagated to another account, be aware that a system note is created only in the account where the change was made.

Notes Are Logged Only for Fields You Have Permission to Modify

In general, if you install an integration record, system notes are created only for those fields that you are permitted to change. For that reason, the same record, when viewed in the account that owns it, contains system notes for a greater number of fields.

This distinction may be particularly noticeable if an account owner makes changes to fields that other accounts are not permitted to change. These updates are propagated to all accounts that have installed the record, but system notes are not created in the other accounts.

For details on how ownership of an integration record affects system notes for various fields, see the following table.



Created By

When a record is created or installed, a system note is created to show the value of the Created By field. However, the way this field is populated varies, as follows: In the account where the record was created, the field’s value identifies the person who created the record. If the record was installed, the field identifies the person who installed the record.


System notes for the Description field exist only in the owner’s account, even though changes are pushed to all accounts where the record has been installed.


A system note is created for the Name field in an account that installs the record, even though that account does not have the ability to edit the field. In this sense, the Name field is unique among fields that are not modifiable by non-owning accounts. Note also that subsequent changes to the Name field by the account that owns the record are not propagated outside the account that owns the record, even though a bundle update may show a new name for the record.


Data in the Note field is specific to the account where the record is installed. Therefore, a value for the Note field is never set during installation, and no system note is created for it at the time of installation. If you add a value for the field after installation, a system note is created.

Token-based Authentication

System notes for the Token-based Authentication field exist only in the owner’s account, even though changes are pushed to all accounts where the record has been installed.

User Credentials

System notes for the User Credentials field exist only in the owner’s account, even though changes are pushed to all accounts where the record has been installed.

Related Topics

Integration Management
Integration Record Overview
Adding an Integration Record
Application Details for Client Code
Blocking SOAP Web Services Requests
SOAP Web Services Execution Log
Distributing Integration Records
Default Web Services Integrations Record
Using Integration Records in Sandbox Accounts
Token-based Authentication Credentials and Accounts
Using Integration Records in Conjunction With SSO Calls
Removing Integration Records

General Notices