# 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.
{% hint style="warning" %}
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.
{% endhint %}
### Use Cases for Custom Properties
1. **Custom Workflows:** Override default behavior to support specific workflows and automate processes based on custom criteria.
2. **Enhanced Data Synchronization:** Customize how data is synchronized between systems by adding rules and conditions that reflect your business needs.
3. **Detailed Reporting:** Capture additional data points for more comprehensive reporting and analytics.
### How to Access Custom Properties
#### Jira Data Center
1. In the integration setup, go to **Settings** > **Custom Properties**.
2. Click on **Add Property** to define a new custom property.
3. Provide a name for the property and select the appropriate data type (e.g., text, number, date).
4. Specify any default values or conditions that need to be met for this property.
#### Getint On-Premise
1. In the integration setup, go to **System** > **Custom Properties**.
2. Click on **Add Property** to define a new custom property.
3. Provide a name for the property and select the appropriate data type (e.g., text, number, date).
4. 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
1. `CLEAN_UP_MAX_RUNS`
* How many runs Getint cleans up in one cleanup cycle.
2. `CLEAN_UP_INTERVAL_IN_HOURS`
* How long Getint waits between cleanup cycles.
3. `CLEAN_UP_THREADS_COUNT`
* The number of cleanup threads working in parallel.
4. `ENABLED_DETAILED_LOGGING`
* Getint prints more detailed information about errors.
5. `MAX_NUMBER_OF_ITEMS_PER_RUN`
* The maximum number of items that Getint can sync per run.
6. `MAXIMUM_AGE_OF_LOGS_IN_DAYS`
* Duration for which Getint will keep sync data.
7. `FF_SKIP_COMMENTS_CREATED_BEFORE`
* Comments created before a specific date (e.g., 2024-01-01) will be skipped during syncs.
8. `DO_NOT_STORE_BROKE_PIPELINE_SYNCS`
* If set to true, Getint won't save information about items that failed to sync. Useful for saving storage and when filters are applied.
9. `MAX_HISTORY_CHANGES_PER_INTEGRATION_SUITE`
* Controls how many integration changes are stored in Getint (default: 20).
#### Specific Flags for Data Cleanup
1. `CLEAN_UP_INTERVAL_IN_HOURS`
* Interval in hours for cleanup (default: 4).
2. `NUMBER_OF_RUNS_TO_CLEAN_UP`
* The 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.
{% hint style="info" %}
**Available for**: On-Premise, Jira Data Center, and Cloud deployments.
{% endhint %}
* 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_TRACE` is 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_TRACE`
* **Property 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_CONFIG`
* `SALESFORCE_RETRY_LOGIC_CONFIG`
Example configuration:
```
JIRA_RETRY_LOGIC_CONFIG
{
"ENABLED": "true",
"INITIAL_WAIT_MS": "500",
"MAX_WAIT_MS": "15000",
"MAX_ATTEMPTS": "4",
"MULTIPLIER": "2"
}
SALESFORCE_RETRY_LOGIC_CONFIG
{
"ENABLED": "true",
"INITIAL_WAIT_MS": "500",
"MAX_WAIT_MS": "15000",
"MAX_ATTEMPTS": "4",
"MULTIPLIER": "2"
}
```
**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):
```
SNOW_RETRY_LOGIC_CONFIG
{
"ENABLED": "true",
"INITIAL_WAIT_MS": "500",
"MAX_WAIT_MS": "15000",
"MAX_ATTEMPTS": "4",
"MULTIPLIER": "2"
}
```
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`, or `SNOW_RETRY_LOGIC_CONFIG` is 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.
{% hint style="danger" %}
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.
{% endhint %}
#### Save and Test the Configuration
1. Once you have configured the custom properties, save the settings.
2. 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.](https://getint.io/help-center)
