How to Override Getint Behavior Using Custom Properties
Custom properties in Getint give you the ability to tweak and adjust how Getint operates by default to match your specific needs. By utilizing these properties, you can boost both the functionality and flexibility of your integrations, ensuring they match your business processes.
Please note that this feature is only supported for Jira Data Center apps and Getint On-premise customers. This guide is not meant for Jira Software.
Use Cases for Custom Properties
Custom Workflows: Override default behavior to support specific workflows and automate processes based on custom criteria.
Enhanced Data Synchronization: Customize how data is synchronized between systems by adding rules and conditions that reflect your business needs.
Detailed Reporting: Capture additional data points for more comprehensive reporting and analytics.
How to Access Custom Properties
Jira Data Center
In the integration setup, go to Settings > Custom Properties.
Click on Add Property to define a new custom property.
Provide a name for the property and select the appropriate data type (e.g., text, number, date).
Specify any default values or conditions that need to be met for this property.
Getint On-Premise
In the integration setup, go to System > Custom Properties.
Click on Add Property to define a new custom property.
Provide a name for the property and select the appropriate data type (e.g., text, number, date).
Specify any default values or conditions that need to be met for this property.
Configure These Properties Using Available Flags
Use available flags to determine how these properties should influence the integration behavior. For example, you can set conditions to trigger specific actions or override default flags based on the custom property values.
Values That Can Be Modified
CLEAN_UP_MAX_RUNSHow many runs Getint cleans up in one cleanup cycle.
CLEAN_UP_INTERVAL_IN_HOURSHow long Getint waits between cleanup cycles.
CLEAN_UP_THREADS_COUNTThe number of cleanup threads working in parallel.
ENABLED_DETAILED_LOGGINGGetint prints more detailed information about errors.
MAX_NUMBER_OF_ITEMS_PER_RUNThe maximum number of items that Getint can sync per run.
MAXIMUM_AGE_OF_LOGS_IN_DAYSDuration for which Getint will keep sync data.
FF_SKIP_COMMENTS_CREATED_BEFOREComments created before a specific date (e.g., 2024-01-01) will be skipped during syncs.
DO_NOT_STORE_BROKE_PIPELINE_SYNCSIf set to true, Getint won't save information about items that failed to sync. Useful for saving storage and when filters are applied.
MAX_HISTORY_CHANGES_PER_INTEGRATION_SUITEControls how many integration changes are stored in Getint (default: 20).
Specific Flags for Data Cleanup
CLEAN_UP_INTERVAL_IN_HOURSInterval in hours for cleanup (default: 4).
NUMBER_OF_RUNS_TO_CLEAN_UPThe number of runs to clean per cleanup cycle (default: 500). Getint performs 10 cycles per cleanup, removing 5.000 runs of data per cleanup.
Specific Flag to Show Stack Traces
LOG_STACK_TRACE is a boolean custom property that controls whether advanced scripting errors write full stack traces to logs, and it is disabled by default.
Available for: On-Premise, Jira Data Center, and Cloud deployments.
By default, stack traces are not shown in regular logs or advanced scripting logs to avoid exposing stack traces in regular logs
When
LOG_STACK_TRACEis set to true, advanced scripting errors can include stack traces in the log output.To enable the property, add a new entry with the following details:
Property Name:
LOG_STACK_TRACEProperty Value:
true
Specific Flag for Retry Logic Configuration
Retry logic is a configurable exponential backoff mechanism for Jira, Salesforce, and ServiceNow that also refreshes OAuth tokens mid-run, starting from specific connector versions.
Purpose
Reduce failed syncs caused by Atlassian, Salesforce, or ServiceNow API rate limits and temporary outages.
Allow customers to tune retry behavior per environment using custom properties, based on their own traffic profile and vendor limits.
Minimize duplicate records and partial runs by applying controlled retries with exponential backoff.
Jira and Salesforce Configuration
Use the following custom properties to control the retry policy for Jira and Salesforce:
JIRA_RETRY_LOGIC_CONFIGSALESFORCE_RETRY_LOGIC_CONFIG
Example configuration:
Parameter Details:
ENABLED: Turns retry logic on or off.INITIAL_WAIT_MS: Initial wait time before the first retry attempt (e.g., 500 ms = 0.5 s).MAX_WAIT_MS: Maximum wait time between retries (e.g. 15000 ms = 15 s).MAX_ATTEMPTS: Maximum number of retry attempts for a single request.MULTIPLIER: Factor used to increase the delay between subsequent attempts (e.g., 2 = doubles the wait time each retry).
ServiceNow Configuration
For ServiceNow, use the SNOW_RETRY_LOGIC_CONFIG custom property (available since v1.98):
Behavior is equivalent to the Jira/Salesforce retry property:
Enables retries on transient errors (e.g., 429, 503).
Uses the same exponential backoff parameters (
ENABLED, INITIAL_WAIT_MS, MAX_WAIT_MS, MAX_ATTEMPTS, MULTIPLIER).
OAuth Token Refresh Behavior
When
JIRA_RETRY_LOGIC_CONFIG,SALESFORCE_RETRY_LOGIC_CONFIG, orSNOW_RETRY_LOGIC_CONFIGis enabled, the connector can refresh the OAuth token in the middle of a run.This reduces failures caused by access tokens expiring during long-running synchronizations.
Monitor external service quotas like Salesforce API limits closely. Persistent 429 responses indicate fundamental capacity issues—retries provide temporary relief but won't bypass plan restrictions, so review your vendor tier or optimize sync frequency/volume instead.
Save and Test the Configuration
Once you have configured the custom properties, save the settings.
Test your integration(s) to ensure that the custom properties are correctly influencing how Getint operates.
Support and Assistance
Our support team is available to provide guidance and assistance with configuring custom properties and overriding integration behaviors. For any questions or support needs, don’t hesitate to reach out to us here.
Last updated
Was this helpful?