Yes, this is supported. The setup of that integration is identical to the setup of projects synchronization between different Jira instances.
Yes. Integration of all Jira version combinations is supported. E.g. you can integrate Jira Cloud with Jira Cloud, Jira Cloud with Jira Server, Jira Server with Jira Data Center etc.
We support Jira Cloud and Jira Server / Data Center (DC) >= 7.0
The Standard SLA is 24h response time. For customers with premium support, except for standard support channels, we also offer invitations to our Slack and faster response time. All that to provide you with direct access to the Tech team of our product, which can help or resolve your issues when they appear.
Not at this moment. You can use one of the tools from the following list https://www.g2.com/categories/cloud-infrastructure-monitoring. You can configure the tool to alert you when the server or the installed getint.io platform encounters any errors.
Yes. It is a standalone platform separated from the Apps it integrates (including Jira).
Getint.io Jira apps are only used for Licensing purposes, but the whole configuration, UI, and synchronization logic is stored and performed outside of Jira. That's why for Jira Server / DC which are behind a firewall it's essential to use the On-Premise version of getint.io. Read more on the Architecture pages.
Yes, you need to open a port in a firewall - or you need to host it yourself.
You can set up integrations in parallel, creating multiple integrations threads, and then you can run those threads at the same time. Each integration/integrations will be run on separate threads so they will not wait with the start before the other finish.
We do not provide scripting like Exalate. With time, scripting becomes very complex and can provide unstable behavior. In the end, it's usually hard to maintain. We are supporting variables and logical conditions. Using the variables you can build a new value for the field, in a dynamic way. For example:
Not now. We are focusing on issues with data synchronization. Although we are receiving more and more questions regarding this so follow the Roadmap.
No. We are not planning to implement that feature.
When you are setting up the integration, for each of the apps you can provide additional query which will be appended to the request sent to the app when searching for items to sync. When this query is provided, the migration feature will use it. This way, you can filter out items that should be picked up for migration.
Jira Cloud - install one of our Jira cloud apps. Then you can access getint.io from the Apps menu.
To build up the integration, in both cases you will need to have the credentials of the users of the apps you want to integrate. E.g. if you integrate Jira Cloud and Asana, you need to have email address + the token of the user existing in Jira, and the token of the user in Asana. Then we can use those credentials to fetch all configurations needed to build up integrations and later on perform syncs.
For Jira Server - you need to install getint.io on the Linux machine if your Jira Server is behind the firewall. If your Jira is not behind firewall you can create account on our SaaS instance. In both cases reach out to us at [email protected]
The user which has permission to the projects and items you want to synchronize. We do not require administrator permissions from the users as we are not performing any modifications in the app configuration.
Only for the Jira Cloud, we obligatory require to install one of our Jira Cloud apps, available on Atlassian Marketplace. For the Jira Server / DC it is not mandatory, reach out to us to discuss the licensing.
We do not require to install anything on Azure DevOps, Servicenow etc. (all other apps other than Jira) we are not requiring to install apps.
- When your Jira Server / Jira Data Center is behind the firewall.
- When your security policy requires you to have all the data stored in your company infrastructure
- When you are going to synchronize a huge amount of items e.g. thousands of issues per day
Task creation date can not be mapped because it is calculated on creation by the app in which the item is created. Thus that you can not override that. Although, you can save the original creation date in a Custom Field. Reach out to us to learn how.
It depends on the default mapping setting you have set up.
When getint.io can not connect with the apps during performing integration, because of e.g. no internet connection or the app is offline, it will fail to run and try again after a setup interval. It will again try to fetch items changed after a given time.
Getint.io is using the standard official REST API to communicate with the Jira. Jira is designed to handle a huge amount of REST API calls so it should not impact the performance. Getint.io is designed to perform as least of requests as possible.
For Jira Data Center, you can also consider setting up a dedicated Node that will handle the REST API calls.
We release new versions at least once per month. Minor releases are done more often though.
It should continue to work normally because the breaking API changes are introduced by apps/tools vendors very rarely. Although if something will be broken, you will start to see the errors. Reach out to us when this occurs.
There is a special option to filter out comments by visibility value.
We are not having this feature at the moment, but we plan to introduce it soon.
The On-Premise getint.io version is a Java Sprint application using PostgreSQL and NGINX. Thus that it can be monitored using different monitoring applications.
We leave it up to customers to decide what monitoring tool suites them best. You can introduce some Application-level monitoring or Logs level monitoring as well because all logs are
Yes, one of our biggest focuses was Reporting, providing as much as possible information regarding the performed synchronizations and collected errors, as possible. Thanks to this, we are able to solve most of the errors very very fast.
In the On-Premise version, you can provide 0s interval, which means that integration will start to sync changes immediately after its finish, so it can be almost real-time.
It handles both scenarios.
Yes, definitely :)
To calculate the price for Jira Server:
Apps are billed based on the number of users in your Atlassian product. For Jira 7.0 or later, the app tier should match the maximum tier of the licensed Jira products on your instance. For example, if you're running Jira Software (500 users) and Jira Service Management (25 agents) on the same instance, you should purchase the 500-user tier for apps. For versions of Jira prior to 7.0, the app tier should match the licensed user tier for Jira. Even if fewer users want to use the app than your Jira license, the two licenses should match exactly. Note: While this app has features specific to Jira Service Management, the app is technically available across the whole Jira instance. Therefore the above guidelines for the license tier still apply.
The price for integrations that do not include Jira, there is a flat price of $99.99/month.
In getint.io you pay for each connection (Jira-Asana is one connection, Asana-Service Now is another one).
The setup of basic integration takes just about 3 minutes. This will let you sync the basic scope (title+description+attachments+comments). From that point, you can start working on more advanced cases to cover even very complicated cases.
According to Atlassian recommendations for delivering Jira Cloud app, our Cloud apps are hosted on our servers and then served within iframes in a Jira Cloud to our customers. Whenever we have a new version, we are releasing it into our servers so the newest version is served to cloud customers. Thus that, there is no reason for customers to try to update to a new version, because they should be already on the newest one. We are responsible for updating getint.io cloud apps versions.